Repository navigation
Conversation
HAPI 2.3 (hapi-base and hapi-structures-v21 to v26), jtds 1.3.1, sqlite-jdbc 3.43.2.1, rsyntaxtextarea 2.5.6, autocomplete 2.5.4 and languagesupport 2.5.6 now resolve from Maven Central, and dcm4che 2.0.29 from the dcm4che.org repository. The dcm4che jars are byte-identical to the committed copies. The others hold the same entries in different zip packaging, and sqlite-jdbc's manifest also orders its OSGi headers differently. The placements keep every file at its previous path and name, so server/setup still has the same 712 files. PDFRenderer.jar stays committed. Its Maven artifact is signed, and the signing step's jar umf would invalidate that signature. Signed-off-by: Sean Rowe <sean@connectivitywise.com>
f3d7814 to
a353191
Compare
|
@ssrowe, is this ready for review? You've got two already. |
tonygermano
left a comment
There was a problem hiding this comment.
|
Something we don't need to address in this PR, but we do need to be careful about is that with nearly everything coming from maven central now, there's a good chance that renovate will update a library that belongs to an extension, and it won't update the plugin.xml to match. |
| # languagesupport, rsyntaxtextarea and sqlite-jdbc hold the same entries | ||
| # as the vendored jars in different zip packaging (sqlite-jdbc's | ||
| # manifest also orders its OSGi headers differently). | ||
| # dcm4che comes from the dcm4che.org repository. |
There was a problem hiding this comment.
I don't think these comments are going to be useful to someone looking at this file later. The commit message already explains most of these details.
For rsyntaxtextarea and related fifesoft libs, look how awssdk-netty-nio-client and jackson-core are commented to note that they are off from the rest of the family. I'm assuming these should all eventually be aligned since rsyntaxtextarea and languagesupport are the same and autocomplete is only a couple patch versions behind.
| awssdk = "2.15.28" | ||
| bouncycastle = "1.78.1" | ||
| byte-buddy = "1.14.13" | ||
| dcm4che = "2.0.29" |
There was a problem hiding this comment.
May want to put a comment here to remove the custom repo from build.gradle and pull from maven central when upgrading to 3+ so it will show up in the PR if the version gets bumped.
| reactive-streams = { module = "org.reactivestreams:reactive-streams", version = "1.0.3" } | ||
| reflections = { module = "org.reflections:reflections", version = "0.9.10" } | ||
| rhino = { module = "org.mozilla:rhino", version = "1.7.13" } | ||
| rsyntaxtextarea = { module = "com.fifesoft:rsyntaxtextarea", version = "2.5.6" } |
There was a problem hiding this comment.
Shouldn't this be fifesoft-rsyntaxtextarea?
Part of #472, and the "byte-identical jars" item in #337.
Replaces 29 committed jars with the Maven artifacts they match:
hapi-baseandhapi-structures-v21tov26(also covered in Update HAPI to 2.6.0 to close XXE vulnerability #448)The dcm4che jars are byte-identical. The others have exact class files in different zip packaging, and sqlite-jdbc's manifest also orders its OSGi headers differently, so a full diff won't pass. The original source for these jars is unknown.
Need a decision regarding
PDFRenderer.jar. Its Maven artifact is signed, and the signing step'sjar umffor extension jars, invalidates the signature.Verification
server/setupbuilt before and after has the same 712 files at the same paths. Only the swapped jars differ, and only in zip metadata, apart from the sqlite-jdbc manifest. The extension zips inserver/distare byte-identical.gradle/verification-metadata.xmlregenerated with a cold cache, per CONTRIBUTING.