Bugzilla – Full Text Bug Listing
| Summary: | Temp disabled RAP related components in Mars stream | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [RT] RAP | Reporter: | David Williams <david_williams> | ||||
| Component: | Releng | Assignee: | Project Inbox <rap-inbox> | ||||
| Status: | RESOLVED FIXED | QA Contact: | |||||
| Severity: | major | ||||||
| Priority: | P1 | CC: | dennis.huebner, t_hilker | ||||
| Version: | 3.0 | ||||||
| Target Milestone: | 3.0 M5 | ||||||
| Hardware: | PC | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
|
Description
David Williams
(In reply to comment #0) > Both the Mars and Luna aggregation builds have been failing with this message: ... Regarding Luna: Are you sure that the Luna build has the same problem? - the three mentioned *rap.b3aggrcon files haven't been changed lately and they are not disabled in the Luna_maintenance branch - the verification of the current Luna_maintenance branch finishes successfully (without downloading the actual artifacts) - the last simrel.luna.runaggregator job #788 finished successfully - earlier failures up to build #785 seem to be caused by a change in the Birt p2 repository which has been fixed in build #786 Either I'm looking at the wrong location or this doesn't affect Luna at all. Regarding Mars... Our RAP 3.0 M2 Mars contribution includes org.eclipse.core.databinding.beans.source but not the bundle that belongs to that source bundle. All other o.e.core.databinding.* bundles are there as expected. Very strange. In our nightly builds for M3 everything looks good and the updated bundle is included (see [1]). I think I'm going to publish an early RAP Mars M3 *candidate* and re-enable the three b3aggrcon files in master. [1] https://hudson.eclipse.org/rap/job/rap-head-runtime/ws/org.eclipse.rap/releng/org.eclipse.rap.build/repository.mars/target/repository/plugins/ There's something broken and I have to figure out what... If I'm running the RAP build (CBI/Tycho/Maven) with signing enabled, only the source bundle finds its way into the ZIP archive with the p2 repository [1]. We are signing with the CBI 1.1.1 signing plugin using Tycho 0.21.0 If I'm not signing the bundles, i.e. deactivate the signing profile in the build, everything is fine [2]. [1] https://hudson.eclipse.org/rap/job/rap-head-runtime/470/consoleFull - signed [2] https://hudson.eclipse.org/rap/job/rap-head-runtime/469/consoleFull - unsigned (In reply to Markus Knauer from comment #1) > (In reply to comment #0) > > Both the Mars and Luna aggregation builds have been failing with this message: ... > > Regarding Luna: Are you sure that the Luna build has the same problem? > No, sorry for the misleading remark ... I just meant "I hadn't looked at it". (In reply to Markus Knauer from comment #3) > There's something broken and I have to figure out what... > > If I'm running the RAP build (CBI/Tycho/Maven) with signing enabled, only > the source bundle finds its way into the ZIP archive with the p2 repository > [1]. We are signing with the CBI 1.1.1 signing plugin using Tycho 0.21.0 > > If I'm not signing the bundles, i.e. deactivate the signing profile in the > build, everything is fine [2]. > > > [1] https://hudson.eclipse.org/rap/job/rap-head-runtime/470/consoleFull - > signed > [2] https://hudson.eclipse.org/rap/job/rap-head-runtime/469/consoleFull - > unsigned That's interesting, though frustrating. I think running with the debug flag (-X) might produce more output from the jar signer, though the logs can end up being 300 Megabytes or so! (at least, in Platform). Any "nested jars"? Does it happen to be huge? Those are the types of things I've seen fail, in the past. Otherwise, maybe just can communicate to TSA, but, that wouldn't make sense, if always the same jar. Oh, vague memory of another case, where the jar wasn't valid (unzip -t xxx.jar) would tell you ... but think in that case it was intentionally a "bad jar" (for testing) and I think Thanh fixed that case? Created attachment 248554 [details] p2 mirror workaround There are always the same two bundle missing (see below). > org.eclipse.core.databinding.beans_1.2.200.v20140910-2107.jar > org.eclipse.core.databinding.beans_1.2.200.v20140910-2107.jar.pack.gz > org.eclipse.core.runtime_3.10.0.v20140724-1132.jar > org.eclipse.core.runtime_3.10.0.v20140724-1132.jar.pack.gz I compared their metadata (IU with id='org.eclipse.core.databinding.beans') in the released Luna SR1 repository with the Mars M2 metadata, and there no notable changes except the expected change of versions. I had the hope that maybe there was a little change upstream that could end in a bigger change in our repository. Since I'm running out of time, I experimented with a small p2 mirror script that I'm attaching to the bug. This uses a (local) RAP Runtime p2 repository and the Platform M3 p2 repository to mirror all artifacts (including the missing ones). I will contribute this as a RAP-pre-M3 and will try to re-enable the missing contributions in the Mars Simultaneous Release. Investigation will go on... but even if not solved in time for our M3 contribution tomorrow we've got a workaround. I've enabled all disabled contributions again based on the workaround from the last comment. commit 1d9228e196ec08f6b4045be430fc03127cc55468 Enabe RAP-dependend contributions with a RAP pre-M3 build *** Bug 441024 has been marked as a duplicate of this bug. *** Fixed by migrating our build to use the Mars/4.5 stream only... RAP 3.0 M5 will contain all the required bundles. Up to RAP 3.0 M4 we were using Luna (R, SR1) as our main build target and provided a compatible p2 repository for Mars. This must have been caused this error with some missing bundles, but it is still unclear to me why it happened only if we enabled signing in our build. (For the records: RAP 3.0 M4 for Mars has been assembled with the same workaround as M3, i.e. manually adding some bundles to make the p2 repository consistent and self-contained. This includes both javax.servlet bundles, 3.0 and 3.1, which is far away from perfect. This and other issues (e.g. Jetty 8.1 -> 9.2) has been fixed for M5.) |