Bugzilla – Full Text Bug Listing
| Summary: | a.jre.javase appears to be at wrong version (1.7.0) | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | David Williams <david_williams> | ||||
| Component: | Releng | Assignee: | David Williams <david_williams> | ||||
| Status: | RESOLVED FIXED | QA Contact: | |||||
| Severity: | blocker | ||||||
| Priority: | P3 | CC: | igor, jan.sievers, pwebster, t-oberlies | ||||
| Version: | 4.5 | ||||||
| Target Milestone: | 4.5 M7 | ||||||
| Hardware: | PC | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Bug Depends on: | |||||||
| Bug Blocks: | 434596 | ||||||
| Attachments: |
|
||||||
|
Description
David Williams
Tobias, Thought you might know something about this? I'm not even sure it's a "problem" ... but ... sure seems like it would be. I started looking at this because a colleague said they started getting "unsatisfied dependency to 'a.jre.javase' while they were mirroring the repository. One thing I've found so far, is that in our "build area", each "repository" made specifically for "a product" (under /target) has a.jre.javase version 1.6 (as well as config.a.jre.javase) ... but, in our main "repository" section, in build area, it has only 1.7.0? Created attachment 252817 [details]
various version numbers of 'a.jre.javase'
The list is hard to read, but in short, it appears that it is the metadata under /targetPlatformRepostory/ that incorrectly has "1.7.0".
I am not sure where it gets it's value from, or if there is anything "we" can do to control it.
Granted, in our final step of producing "our whole repository", one part of that is to mirror a 'targetPlatformRepository' which we do specifically for this type of "a.jre.javase" metadata ... and the equinox.executables.feature. I *might* be able to work around this by picking and choosing specific things from these "pieces" of the build, but ... this is uncertain, and a change from M6. My intuition is that Tycho "moving to Java 7" is somehow the cause of this. I'm moving to "blocking" because some have reported to me they can not "created an installed version of Eclipse or higher packages" since, after all, Eclipse SDK would be seen to be "missing" the dependency on 'a.jre.javase' version 6. Adding others from Tycho team to improve odds that at least one will respond :) Are these "funky IUs" something that you "get" from p2? Or, is it something the builder itself creates? Is there anything "we" are supposed to do in our build to specify "targeted version"? [I have a hard time finding anyone who even knows how to explain these :) ] So, ... I see the a.jre.javase IU does contain 2 new packages: <provided namespace='java.package' name='javax.xml.ws.spi.http' version='0.0.0'/> <provided namespace='java.package' name='javax.swing.plaf.nimbus' version='0.0.0'/> While *we* don't need those, it makes me think the change from Tycho was intentional ... that, plus this old post: https://dev.eclipse.org/mhonarc/lists/tycho-dev/msg00882.html So, guess the question is, if "we" pre-req Java 7? And, if so, how to get Eclipse SDK to "require" a.jre.javase version 1.7.0 instead of 1.6.0. bug 464304 is probably related do you see build failures? If not you can probably ignore these IUs, they are there to satisfy Import-Package requirements to JDK packages. The fact that the product publisher generates them hardcoded to 1.6 is more like a bug in p2 IMHO (product publishing and generating the JRE IUs are mixed up concerns) (In reply to David Williams from comment #1) > I started looking at this because a colleague said they started getting > "unsatisfied dependency to 'a.jre.javase' while they were mirroring the > repository. we'd need steps to reproduce this error. Some general remarks: - https://wiki.eclipse.org/Tycho/Execution_Environments should document how you can configure EEs and what the effects are - folders or files like target/targetPlatformRepository/ target/p2content.xml are Tycho-internal and intermediate build results. The only thing relevant for another build consuming your build is the final build result target/repository/ of you eclipse-repository module(s). According to attached list and looking at bug 387701, the line eclipse.platform.repository/target/repository/content.xml:<unit id="config.a.jre.javase" version="1.7.0" singleton="false"> may be a problem if there are products in this repo which are referencing IU config.a.jre.javase with perfect version match to version 1.6.0 (In reply to Jan Sievers from comment #7) > bug 464304 is probably related > > do you see build failures? > > If not you can probably ignore these IUs, they are there to satisfy > Import-Package requirements to JDK packages. The fact that the product > publisher generates them hardcoded to 1.6 is more like a bug in p2 IMHO > (product publishing and generating the JRE IUs are mixed up concerns) Yes, some adopters are, even though we don't. (because, for example, our "product" requires "a.jre.javase" and "config.a.jre.javase" which is "unsatisfied dependency" in our repo). Today I'll be both looking to get rid of the dependency on your "internals". Not sure how, yet. And will also look at using following in our "products" requires.0.namespace=org.eclipse.equinox.p2.iu requires.0.name=a.jre.javase requires.0.range=[1.7.0,1.7.0] requires.1.namespace=org.eclipse.equinox.p2.iu requires.1.name=config.a.jre.javase requires.1.range=[1.7.0,1.7.0] I think 1.7.0 would be conceptually accurate for "Eclipse SDK" ... But, 1.6.0 would be (still) accurate for some equinox "pieces", so we might end up with both 1.7 and 1.6 in our repo. But, as far as I can tell no where do we specify any dependencies on those "fake" IUs ... so, seems odd they would change. (Put another way, how does targetRepository/conent.xml "decide" which to use? ... almost seems "hard coded" somewhere in Tycho?). Doubt I'll have any immediate time to create "demo test case". But, appreciate any response at all, Jan. Thanks very much. (In reply to David Williams from comment #9) > But, as far as I can tell no where do we specify any dependencies on those > "fake" IUs ... Well, I was a little bit wrong about this. There are places we try to create "targets" to use for PDE, and they included _mirrored_ versions of "a.jre.javase". So, that's probably part of the complication. my bug. "my" fault.
The "mismatch" of having a.jre.javase version 1.7.0 in our repository, even though we we have "products" that require a.jre.javase 1.6.0 is partially due to us having that one mirroring of "/target/targetPlatformRepository" -- a Tycho "internal" (which must have changed lately as Tycho 0.23.0-SNAPSHOT "moved to be built on 1.7" -- AND us having a few spots where we mirrored that "fake IU" (with no version number specified, so we "got the highest"). (Only version 1.7.0 was in "/target/targetPlatformRepository" ... but, our others had the 1.6.0 version).
And, I say "my" fault, because as far as I can tell, we completely do not need to mirror that "/target/targetPlatformRepository" meta data. Perhaps at some early point we did -- it's been there ever since I first was given the "build prototype" -- but removing it makes no difference to our resulting repo, except that we no longer have 1.7.0 of a.jre.javase in it, and now have the 1.6.0 version.
For historical completeness, there is comment near the mirroring of 'targetPlatformRepository' that says:
<!-- This config/executable p2 metadata should be in any of the "product" targetPlatformRepoositories,
I'd just arbitrarily picked "platform" as the one to use to get our final versions from, for our
main repository.
-->
But, as far as I can tell, we have "everything", even if don't include it.
CCing Paul, as probably author?
Paul, it was so long ago, I doubt you'll even recall, but if there is anything I'm missing, be sure to let me know.
Of course, there's been many other changes to the build since those early days, so I may have "fixed" something, without even knowing it.
Plan to remove in time for Wednesday's 8 AM build. (I have not "ran unit tests" on results ... in theory that might reveal something I am missing ... but, I'd find that pretty surprising. But "plan B" would be to include a version when we mirror those a.jre.javase IUs).
There's another "random" change I'm making with this main fix. In this same "repository pom", there's a line that has said (I think from the very beginning) <!-- TODO this needs to be o.e.equinox.executable --> <id>org.eclipse.equinox.executable.feature.group</id> So, I am going to change to <id>org.eclipse.equinox.executable</id> We actually have both in our main repo, and at this point is this large pom, we are actually creating one of our "subset" repos, which are available on DL page. The one for "rcp sdk". Not sure if anyone even uses that :/ But, I do know for "things that are supposed to be like the delta pack" then org.eclipse.equinox.executable is the correct IU, so am assuming that's what's desired here. http://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator.git/commit/?id=a09340221bcb1126218c7f1fc2561d9567da489b As a closing comment/question ... the "failing case" I know about, was a case where someone was "building a product" and as part of that they built on-top of our "product" (that is, the literal o.e.sdk.ide), so that was part of what they mirroring. I'm not sure if that is a good practice. (Does anyone else?) I know many do it, (including EPP, I believe, with Platform Binary product) ... but it seems to me there is so much "meta data" around products, it'd always be tricky. At the same time, I know it is possible to have more than one product installed, and you run the one you want with a -product argument. So ... if anyone knows any general rules or document, that'd be good. Or, may it always should be ok, and I'm just a worrier? Well, one more closing comment :) Of all the ways I tried, to get our products to use a.jre.javase version 1.7.0, none of them worked ... and, honestly, the most straightforward way I saw (and did not try) was mentioned in an old Tycho test case, which, I'll quote here verbatim. Found at https://github.com/eclipse/tycho/blob/master/tycho-its/projects/eeProfile.java7/repository2/requiresJava7Profile.p2.inf = = = = = = = # these dependencies should be generated automatically; until then, the following should be a workaround: requires.0.namespace=org.eclipse.equinox.p2.iu requires.0.name=a.jre.javase requires.0.range=[1.7.0,1.7.0] requires.1.namespace=org.eclipse.equinox.p2.iu requires.1.name=config.a.jre.javase requires.1.range=[1.7.0,1.7.0] |