Split packages have different signatures #2335
Comments
|
I think you're kind of hosed. I was not keeping track that we have yet more split packages than I was considering, being focused mostly on the core runtime parts. We really need some type of automated test for split-packages-with-different-signatures. 😭 But of course who wants to work on that or pay for that? |
|
One possible solution is to just abandon jarsigner in Platform and go fully PGP. |
I can only second that. Jarsigner is causing more trouble than it's worth. |
|
A preliminary test suggests that the following packages are split across bundles with different signing certificates in the current 4.34 I-builds:
It's easy enough to force a new qualifier which forces a new signature. But when we publish to Maven Central the minor version needs to be incremented (different from what's already been published before) in order to publish a new version. |
- The RepositoryIntegrityAnalyzer supports a -packages option to enable the reporting and testing of provided packages. - Improve the setup and target platform to avoid the older unsigned version of org.apache.commons.collections. eclipse-platform/eclipse.platform.releng.aggregator#2335
|
There are now generated reports: with details about split packages with difference signatures:
There are also junit test results:
Each test result provides details about the IUs and the certificates involved:
Now we will need to bump versions to eliminate the problems. Going forward, we will detect new problems within a day, i.e., long before we publish to Maven Central. |
- Both org.eclipse.equinox.supplement and org.eclipse.osgi.services can't really have inconsistent signatures because they don't really contain the provided packages. eclipse-platform/eclipse.platform.releng.aggregator#2335
- Both need to be bumped because neither is signed by the latest available signing certificate. eclipse-platform/eclipse.platform.releng.aggregator#2335
- Both need to be bumped because neither is signed by the latest available signing certificate. eclipse-platform#2335
- Both need to be bumped because neither is signed by the latest available signing certificate. eclipse-platform/eclipse.platform.releng.aggregator#2335
- Both need to be bumped because neither is signed by the latest available signing certificate. eclipse-platform#2335
Thank you Ed for this! Ideally this test would be added e.g. to the platform-releng-aggregator repository and makes the I-build fail if there are inconsistent signatures. Maybe the report could be created and evaluated as part of the aggregation of the SDK p2-repo? Otherwise I fear you'll be the only one paying attention to those tests and and taking care of failures, because most of the SDK committers won't have a look at Oomph's tests. But if the I-build fails the audience should be much wider. |
|
This job does the work: https://ci.eclipse.org/oomph/job/repository-analyzer Any ci instance could define their own job for doing the work, e.g., like SimRel does: https://ci.eclipse.org/simrel/job/simrel.oomph.repository-analyzer.test/ It's easy to give/get attention for failure regardless of where the job is hosted:
E.g., for this job I make sure that it gets my personal attention if there is a failure: https://ci.eclipse.org/releng/view/Publish%20to%20Maven/job/CBIaggregator
The application is primarily focused on generating the report, with junit support added later, but it could be tailored only to generate junit test results... I think with the increments done now, we're mostly done until the certificate renews in July of next year, except for this split triplet:
|
- Both need to be bumped because neither is signed by the latest available signing certificate. #2335
|
The latest nightly build is free of split packages with inconsistent signatures: For what it's worth, SNAPSHOT publishing is done nightly: https://repo.eclipse.org/content/repositories/eclipse-snapshots/ The tests should ensure that a recurrence of this problem will be noticed with 24 hours and will be fixed before publishing to Maven Central. |
- Both need to be bumped because neither is signed by the latest available signing certificate. eclipse-platform/eclipse.platform.releng.aggregator#2335
For licensing reasons, we must run an obfuscator in our code which goes through the bytecode of all our dependencies. After updating to the latest Eclipse 4.33 I am getting the following error:
This seems related to the discussion here: #2044.
The bundle
org.eclipse.texthasn't had an update since the previous release 4.32 (build qualifier is 20240524), butorg.eclipse.jface.texthas (qualifier 20240816). I think this might've just been the first error that happened, but I expect that the same error would happen with the other split packages.Is there anything we can do to fix this? Otherwise it seems we won't be able to update to the latest Eclipse.
The text was updated successfully, but these errors were encountered: