OPSC-16690 Upgraded Jython version to 2.7.3 from frozen-mirror #16
Conversation
Fixes regression in launcher that prevents running from bin directory.
…rous tests. Issue is kept open to discuss better future solutions.
…ibs where an update attempt caused notable issues were left unmodified.
This removes an obsolete defence against encoding errors during the processing of exceptions, which is now dealt with in Py.dispayException.
Problem was a missing assignment to the message variable. Also brought words closer to CPython 2.7.13.
…s._args_from_interpreter_flags.
These functions now match CPython expectations. In many cases, the root cause was in _socket.py.
This partially backs out cffe5b824a21, to restore synchronisation, but keeps the IOD singleton pattern to protect the type registry. It backs out f3458ef83e08, now unnecessary with PyType synchronised. See also discussion in #2487.
This was a regresion caused when trying to deal with non-ascii paths in the preparation of a log message. Thanks to James Mudd for diagnosing this. Also jython#86.
We allow up to 2 seconds discrepancy in the logic that decides whether to re-compile .py source to $py.class files. This is to accommodate the rounding of last-modified time that occurs when storing and extracting files from a JAR, as during installation. We choose to round times down when JARring and allow 2 seconds positive difference in the check. This has benefits beyond #2862, in avoiding spurious recompilation, so is made a distinct commit. At the same time the implications of #2862 are arguably not addressed fully until the JAR cache is made user-local. --HG-- extra : amend_source : b01f31c727008f16808e4095db542f9af3949967
We no longer try to cache every user's JARs in the installation directory, ineffective since fix of #2044. Behaviour for applications that set an absolute location (or skip) is unchanged.
If the map was modified during a call to keys(), the keyset would change size and cause an ArrayIndexOutOfBoundsException. This creates a copy of the keyset and uses that throughout the method. --HG-- extra : amend_source : 025dd98595b444af0c4ffb67ae4bd4252fb752b4
Shading the Bouncy Castle classes in our JAR makes them untrusted as a security provider. We document that to work around this, users provide the JARs directly.
Update version numbers. Add jffi-dll-droppings to .hgignore so as to avoid complaints from the build after test.
... whilst hoping the next release is actually 2.7.2
…o we can know if they failed
Fix options so they actually work, set hard defaults
nisanth-datastax
force-pushed
the
OPSC-16690
branch
from
de5712b
to
953f55a
Compare
nisanth-datastax
force-pushed
the
OPSC-16690
branch
from
bd39ef4
to
1aea396
Compare
nisanth-datastax
force-pushed
the
OPSC-16690
branch
from
87e193d
to
d2f4171
Compare
Jenkinsfile
Outdated
| usernameVariable: 'ARTIFACTORY_USER', | ||
| passwordVariable: 'ARTIFACTORY_PASSWORD')]) { | ||
| // sh "curl -sSf -u '$ARTIFACTORY_USER:$ARTIFACTORY_PASSWORD' -X PUT -T artifacts/$jarfilename 'https://repo.aws.dsinternal.org/ui/native/dse/com/datastax/opscenter/jython-standalone/2.7.3a1/$jarfilename'" | ||
| sh "curl -v --user $ARTIFACTORY_USER:$ARTIFACTORY_PASSWORD --data-binary artifacts/$jarfilename -X PUT 'https://repo.aws.dsinternal.org/ui/native/dse/com/datastax/opscenter/jython-standalone/2.7.3a1/$jarfilename'" |
There was a problem hiding this comment.
I've been poking at this problem again today and after going through the ui to manually upload the artifact I'm seeing something that might be the problem. The repo the jython artifact is in is 'datastax-public-releases-local'. Any attempt to upload the artifact you make should include that somewhere. In the case here I think it either replaces the 'dse' portion of the url or comes after it.
Here is a link to the artifactory page showing the test artifact I was able to upload and the reference from the opscenterd dependencies:
https://repo.aws.dsinternal.org/ui/repos/tree/General/datastax-public-releases-local/com/datastax/opscenter/jython-standalone/2.7.3a1-test
I hope to be able to test the upload using curl, but I'm not sure if I'll have time during what is left of my workday.
There was a problem hiding this comment.
The upload is working for with curl now with this change @orion104, Thank you!
Does this mean we won't need to use ivy to upload to the artifactory anymore? If so, I will cleanup the ivy related changes in the code and have only the relevant changes.
nisanth-datastax
force-pushed
the
OPSC-16690
branch
4 times, most recently
from
f2510fa
to
7c202f3
Compare
The commit includes changes to Build.xml to version the jython-standalone jar file.The commit also includes a Jenkinsfile which will be used to build the project with ant and publish the artifacts to artifactory.
venu-datastax
force-pushed
the
OPSC-16690
branch
from
7c202f3
to
8b54221
Compare
venu-datastax
requested review from
NagalokeshKanumoori
and removed request for
venu-datastax
|
@vimal-ds This PR is the next step we want to complete. The biggest impediment in merging |
Please refer to the excel sheet below for the details on the delta changes that were done by DataStax on the older Jython version.
https://docs.google.com/spreadsheets/d/19F3S7m8AK2bl0LauBR4eAlFZnBlJ6xMWWCznupXtjSY/edit?gid=0#gid=0
Each of the delta commits have been analysed and the changes which were not handled in the latest Jython upgrade have been added in this pr.