Bugzilla – Full Text Bug Listing
| Summary: | [CBI] none of the generated source features are signed | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Paul Webster <pwebster> | ||||||
| Component: | Releng | Assignee: | David Williams <david_williams> | ||||||
| Status: | VERIFIED FIXED | QA Contact: | |||||||
| Severity: | normal | ||||||||
| Priority: | P3 | CC: | daniel_megert, david_williams | ||||||
| Version: | 4.3 | ||||||||
| Target Milestone: | 4.3 M7 | ||||||||
| Hardware: | PC | ||||||||
| OS: | Linux | ||||||||
| Whiteboard: | |||||||||
| Bug Depends on: | 400733 | ||||||||
| Bug Blocks: | 372792, 393922 | ||||||||
| Attachments: |
|
||||||||
|
Description
Paul Webster
Created attachment 224680 [details]
sign-sources.patch
I believe the issue is due to ordering and inheritance of Maven plugins. In regards to jdt-feature, tycho-source-feature-plugin runs after eclipse-jarsigner-plugin. So this causes org.eclipse.jdt.feature jar to be signed, and then org.eclipse.jdt.sources.feature to be created unsigned since the jarsigner's already run it's signing task.
From what I understand Maven executes plugins in the same phase, in the order they are defined. So in the case of jdt-feature, eclipse-parent/pom.xml defined the jarsigner first, and then the jdt-feature pom inherits that, then define's the tycho-source-feature-plugin in it's own pom.xml. Since generating source feature is defined after the jarsigner plugin definition is inherited it will run after but in this case we actually want it to run before.
The attached patch redefines the eclipse-sign profile inside the jdt-feature pom after the tycho-source-feature-plugin is defined causing the execution order to be correct allowing the source feature to be signed.
I am not sure if this is the most optimal approach but it seems to work in this case. If there is a better solution please comment and let me know.
Created attachment 224743 [details]
eclipse-sign.patch alternate method
Attached patch moves the sign phases to "verify" instead of redefining eclipse-sign profile in the feature poms.
(In reply to comment #2) > Created attachment 224743 [details] > eclipse-sign.patch alternate method > > Attached patch moves the sign phases to "verify" instead of redefining > eclipse-sign profile in the feature poms. Pushed to 3.8, 4.2 and master http://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator.git/commit/?h=R3_8_maintenance&id=d4f7bd34766b30cf63453f568d1ebc6dbd0f8dd3 http://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator.git/commit/?h=R4_2_maintenance&id=aea2265b51ff8229861b461058c9e8212d0a92ec http://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator.git/commit/?id=589f75a5e1124a7f7f2c408da7575b6ca8946a11 It looks like there are still source bundles that aren't being signed: http://dev.eclipse.org/mhonarc/lists/platform-releng-dev/msg21057.html PW I'm down to org.eclipse.help.base.source is not being signed when I update from one SDK to the next. PW I believe everything is being signed now. (for I builds). Please open new bugs on specific cases that are found. (In reply to comment #6) > I believe everything is being signed now. (for I builds). Hard to verify, given that bundle mentioned in comment 0 is not even part of the drop (see bug 400733). Dani you can verify on any source bundle that is produced/generated, which is what this bug was about. Whether or not branding bundles get produced (and signed) should be all be part of bug 400733. There's nothing constructive about leaving this open, just because bug 400733 is not settled, or solved. *** Bug 398028 has been marked as a duplicate of this bug. *** Verified in I20130430-0031. |