Community
Participate
Working Groups
Add a test for split packages with different certificates.
Suggestion to avoid dependencies on build details and so allow implementation in the ManifestBuilder; use the greater than 7 day separation between milestones / RCs. The last touched date of a MANIFEST.MF for a split package must be at most seven days older than the last touched date of any file in the plugins of the other split packages.
(In reply to Ed Willink from comment #1) > Suggestion to avoid dependencies on build details and so allow > implementation in the ManifestBuilder; use the greater than 7 day separation > between milestones / RCs. > > The last touched date of a MANIFEST.MF for a split package must be at most > seven days older than the last touched date of any file in the plugins of > the other split packages. Not sure what this is about. Each I-build can make the check in its own. N-builds are not relevant as those aren't signed.
(In reply to Dani Megert from comment #2) > (In reply to Ed Willink from comment #1) > > Suggestion to avoid dependencies on build details and so allow > Not sure what this is about. Each I-build can make the check in its own. > N-builds are not relevant as those aren't signed. I-build tests detect a problem during build so there is potentially a 24 hour delay between offending commit and detection, and of course a failed I-build. A ManifestBuilder detection will probably detect the problem within 5 minutes, if not 5 seconds. No I-build failure.
(In reply to Ed Willink from comment #3) > (In reply to Dani Megert from comment #2) > > (In reply to Ed Willink from comment #1) > > > Suggestion to avoid dependencies on build details and so allow > > Not sure what this is about. Each I-build can make the check in its own. > > N-builds are not relevant as those aren't signed. > > I-build tests detect a problem during build so there is potentially a 24 > hour delay between offending commit and detection, and of course a failed > I-build. > > A ManifestBuilder detection will probably detect the problem within 5 > minutes, if not 5 seconds. No I-build failure. It's not that easy because - there is only a problem when the certificates mismatch. For that the builder would have to get the current certificate somehow. - In order to give accurate results the workspace would have to always be updated to the latest I-build.
(In reply to Dani Megert from comment #4) > - there is only a problem when the certificates mismatch. For that the True and getting the certificate(s) is very hard from an interactive workspace.. But also the problem only exists for the undesirable practice of split packages, so making split packages 'suffer' by requiring co-MANIFEST.MF touching does not seem to be a terrible imposition to me.
Doing a mass "reset to default assignee" of 52 bugs to help make clear it will (very likely) not be me working on things I had previously planned to work on. I hope this will help prevent the bugs from "getting lost" in other people's queries. Feel free to "take" a bug if appropriate.
We will investigate this in 4.8
Bug 536445 reports a new horror whereby split packages were referenced wirth inadequately tight version bounds thereby allowing careless user version dependencies in Maven builds to mix-and-match their resolutions and get a signer failyure rather than the 'correct' incompatible versions. Please ensure that split packages are tested for tight version cross-dependencies.
There are plans for this. Will revisit in 4.10
Moving out of 4.10. Please re triage appropriately
This one is causing grief, so, should try to resolve for 4.11.
@Kalyan, Any update on this? If not please move it out of 4.11
There are no plans for this now. Removing target
Occurs yet again as Bug 573306.
