Bugzilla – Full Text Bug Listing
| Summary: | objectteams juno contribution requires 3.8 platform | ||
|---|---|---|---|
| Product: | [Technology] CBI | Reporter: | David Williams <david_williams> |
| Component: | CBI p2 Repository Aggregator | Assignee: | Project Inbox <b3.aggregator-inbox> |
| Status: | RESOLVED INVALID | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | daniel_megert, stephan.herrmann, thomas |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Whiteboard: | |||
|
Description
David Williams
You're quite right and sorry for the time you had to spend on investigating. Object Teams is built against the latest and greatest SDK 3.8. And due to our direct requirement of the JDT feature this may well be the culprit you are suspecting. I understood that Indigo requirements are "banned" from Juno repositories, but that 3.8 dependencies are off limits is new to me. Last time I tried to build against SDK 4.2, several bits were still missing (directory.txt, testframework), so I switched back to 3.8. This means that once the SDK has 4.2 as its primary build, I should be able to just flip the switch to 4.2. This in turn means I should stop diverting Kim with requests like running the JDT test on Java 7 ... ;-P (In reply to comment #1) > You're quite right and sorry for the time you had to spend on investigating. > > Object Teams is built against the latest and greatest SDK 3.8. > And due to our direct requirement of the JDT feature this may well be the > culprit you are suspecting. > JDT only has 3.8 dependencies but it is fully included in Juno, hence JDT can't be the reason for dragging full Eclipse SDK 3.8 in. Maybe a bug in how you build things? > I understood that Indigo requirements are "banned" from Juno repositories, but > that 3.8 dependencies are off limits is new to me. 3.8 dependencies are fine as long as you don't hard-code any bundle version dependencies. Though for JDT it shouldn't matter as the 3.8 bits are included in Juno/4.2. Our build has been migrated over some 8 years by now, so, yes, some of it may be a bit outdated by now :) One possible explanation is the dependency on org.eclipse.jdt_3.8.0.v20111130-1318-8-8lFpEFNOfwRc2R3LVOg_u9B15B But, as I'm expecting the switch of the SDK build to help here, shouldn't we just wait? The latest Object Teams build is based on the 4.2 build from http://build.eclipse.org/eclipse/e4/kimtest/build/e4/I20120228-1047/ This build has been successfully picked up by https://hudson.eclipse.org/hudson/view/Repository%20Aggregation/job/juno.runAggregator/282/ Looking at the result I could find no offending artifacts from 3.8 being pulled in. Please let me know if the problem persists and which artifacts are involved. Thanks This seems to be happening again, see bug 370644. To elaborate a little, in my test while investigating bug 370644, I initially exclude the whole contribution, from the repo at http://download.eclipse.org/objectteams/updates/unstable That provides two features org.eclipse.objectteams.otdt.feature.group org.eclipse.objectteams.otequinox.feature.group I've found that I only need to disable org.eclipse.objectteams.otdt.feature.group in order to avoid "pulling in" the 3.8 platform. I think this is the feature that has the alternative "org.eclipse.jdt" bundle. I know you did some special "p2 tricks" so as to only install otdt if explicitly chosen by users, not to simply "fill a need" for "org.eclipse.jdt" but I can not find the but where that was described. Browsing around, using b3 aggregator repository browser, I don't immediately see anything related to "org.eclipse.platform", but do see some fairly specific requirements on "runtime", or something, that might lead to some "indirect" pulling in of the 3.8 platform? From earlier comments, sounds like you do need to "build against" specifically a 4.2 build. Offhand, doesn't seem like that should be required, for your "p2 tricks" so I'm wondering if those need to be refined? Just guessing. (In reply to comment #5) > This seems to be happening again, see bug 370644. This is totally unexpected, the newest build in http://download.eclipse.org/objectteams/updates/unstable does not depend on anything that's not available in http://build.eclipse.org/eclipse/e4/kimtest/build/e4/I20120228-1047/ plus one bundle from orbit. All Object Teams features can be installed in a SDK 4.2M6 without pulling in platform_3.8. From trial-and-error aggregations (using only Eclipse, Equinox and Object Teams contributions) I could narrow this down as follows: - it's *not* caused by our "p2 tricks" (non-greedy reverse dependency from our variant of org.eclipse.jdt.core to our patch feature). - the aggregator stops pulling in platform_3.8 when I disable the following in our patch feature: <requires> <import feature="org.eclipse.jdt" version="3.8.0.v20111130-1318-8-8lFpEFNOfwRe0lvGVLmVw9B15B" patch="true"/> </requires> To make aggregation work even without this necessary declaration I obviously had to rename our jdt.core bundle. Note, that the referenced jdt feature is the exact version contained in 4.2M6. - Even just removing 'patch="true"' fixes the problem. Obviously, this attribute does not express a dependency on platform_3.8. Ergo: I'm suspecting the b3 aggregator to misbehave. The 'patch="true"' directive should not influence the aggregation in this way. Moving to b3 for comments. BTW: I could've saved a couple of hours if b3 could simply spit out a list of what it plans to do instead of needing to actually do all that mirroring. Wouldn't that be a nice feature? :) (In reply to comment #7) > BTW: I could've saved a couple of hours if b3 could simply spit out a list of > what it plans to do instead of needing to actually do all that mirroring. > Wouldn't that be a nice feature? :) Yes, it would. And in some sense we already have it :) Try using --VALIDATE if you run from the command line or just select VALIDATE as the action in the IDE. The aggregator will not tell you exactly what it will do (not sure if that would be useful), but it will report all problems without actually creating anything. I'm a bit rusty on the feature.xml syntax. What exactly does patch="true" mean? What does the requirement look like in the generated IU? You may have to look at whole thing, to make sense of it, but here's snippets from a "real life" IU from a patches repo. You can download the whole archived repo from http://download.eclipse.org/webtools/patches/drops/R3.3.2/P-3.3.2-20120309045727/patches32x-repo-P-3.3.2-20120309045727.zip In these "real life" cases, the key to success is making sure the patch feature is tied to exactly one version of the feature you want the fixes applied to. Sounds like the Objectteam case is sort of "self referential", so not sure what that would look like. HTH = = = = = <unit id='org.eclipse.wst.server_ui.feature.patch.feature.group' version='3.3.2.v20120307_1130-32Ex8s7357393IA557I' singleton='false'> <patchScope> <scope> <requires size='1'> <required namespace='org.eclipse.equinox.p2.iu' name='org.eclipse.wst.server_ui.feature.feature.group' range='0.0.0'/> </requires> </scope> </patchScope> <changes> <change> <from> <required namespace='org.eclipse.equinox.p2.iu' name='org.eclipse.wst.internet.monitor.ui' range='0.0.0'/> </from> <to> <required namespace='org.eclipse.equinox.p2.iu' name='org.eclipse.wst.internet.monitor.ui' range='[1.0.508.v20120307_1126,1.0.508.v20120307_1126]'/> </to> </change> <change> <from> <required namespace='org.eclipse.equinox.p2.iu' name='org.eclipse.wst.server.ui' range='0.0.0'/> </from> <to> <required namespace='org.eclipse.equinox.p2.iu' name='org.eclipse.wst.server.ui' range='[1.3.1.v20120307_1129,1.3.1.v20120307_1129]'/> </to> </change> </changes> <lifeCycle> <required namespace='org.eclipse.equinox.p2.iu' name='org.eclipse.wst.server_ui.feature.feature.group' range='0.0.0' greedy='false'/> </lifeCycle> <update id='org.eclipse.wst.server_ui.feature.patch.feature.group' range='[0.0.0,3.3.2.v20120307_1130-32Ex8s7357393IA557I)' severity='0'/> <provides size='2'> <provided namespace='org.eclipse.equinox.p2.iu' name='org.eclipse.wst.server_ui.feature.patch.feature.group' version='3.3.2.v20120307_1130-32Ex8s7357393IA557I'/> <provided namespace='org.eclipse.equinox.p2.localization' name='df_LT' version='1.0.0'/> </provides> <requires size='1'> <required namespace='org.eclipse.equinox.p2.iu' name='org.eclipse.wst.server_ui.feature.patch.feature.jar' range='[3.3.2.v20120307_1130-32Ex8s7357393IA557I,3.3.2.v20120307_1130-32Ex8s7357393IA557I]'> <filter> (org.eclipse.update.install.features=true) </filter> </required> </requires> (In reply to comment #8) > (In reply to comment #7) > Try using --VALIDATE if you run from the command line or just select VALIDATE > as the action in the IDE. The aggregator will not tell you exactly what it will > do (not sure if that would be useful), but it will report all problems without > actually creating anything. FYI, Its actually "Validate Aggregation" in the UI ... there is a "Validate" also, but that simply validates the model and xml is all well formed. But Stephan is right ... the "problem" doesn't show up until you do the mirroring. So, does take a long time to "see if it is still doing it". I say "problem" in quotes, since it may be, according to what ever boolean logic p2 is coming up with, that there is a perfectly valid solution that just so happens to include both versions of the platform, with are, after all, both available. (I seem to recall some p2 discussions mentioning that some optimizations meant p2 might not always come up with the "best" solution?). And, don't mean to blame p2 here ... just saying its complicated ... and aren't we lucky that the Platform's repo is a little quirky so we can uncover the issue here. And, I don't mean that as sarcastic as it may sound ... there may be "real user" scenarios where they end up with many versions of things available from various combinations of repos ... so so it'd be nice if their updates/installs were deterministic and predictable. Here's snippet's of the objectteam patch fearture, from http://download.eclipse.org/objectteams/updates/unstable/content.jar Sorry, just noticed there are several versions in that content.jar/xml file ... is is just from one of them ... not sure which is "the right" one (or, if there is even a difference). Just trying to give a sample. <unit id='org.eclipse.objectteams.otdt.core.patch.feature.group' version='2.1.0.201201311754' singleton='false'> <patchScope> <scope> <requires size='1'> <required namespace='org.eclipse.equinox.p2.iu' name='org.eclipse.jdt.feature.group' range='0.0.0'/> </requires> </scope> </patchScope> <changes> <change> <from> <required namespace='org.eclipse.equinox.p2.iu' name='org.eclipse.jdt.core' range='0.0.0'/> </from> <to> <required namespace='org.eclipse.equinox.p2.iu' name='org.eclipse.jdt.core' range='[3.8.1.v_OTDT_r210_201201311754,3.8.1.v_OTDT_r210_201201311754]'/> </to> </change> </changes> <lifeCycle> <required namespace='org.eclipse.equinox.p2.iu' name='org.eclipse.jdt.feature.group' range='0.0.0' greedy='false'/> </lifeCycle> <update id='org.eclipse.objectteams.otdt.core.patch.feature.group' range='[0.0.0,2.1.0.201201311754)' severity='0'/> [properties omitted] <provides size='2'> <provided namespace='org.eclipse.equinox.p2.iu' name='org.eclipse.objectteams.otdt.core.patch.feature.group' version='2.1.0.201201311754'/> <provided namespace='org.eclipse.equinox.p2.localization' name='df_LT' version='1.0.0'/> </provides> <requires size='1'> <required namespace='org.eclipse.equinox.p2.iu' name='org.eclipse.objectteams.otdt.core.patch.feature.jar' range='[2.1.0.201201311754,2.1.0.201201311754]'> <filter> (org.eclipse.update.install.features=true) </filter> </required> </requires> [remainder ommitted ] Who makes the 3.8 platform/SDK available on input? Will the aggregation succeed without it and yield a result where there are no duplicates? (In reply to comment #13) > Who makes the 3.8 platform/SDK available on input? equinox.b3aggrcon defines this repo: location="http://download.eclipse.org/eclipse/updates/3.8milestones/S-3.8M6-201203141800/" description="Eclipse and Equinox" > Will the aggregation succeed > without it and yield a result where there are no duplicates? "Validate Aggregation" actually succeeds if I disable the Equinox contribution (i.e., with only Eclipse and Object Teams contributions). I'll report more, once mirroring is done. Would it be possible to slice the "Equinox" repo before contributing its content to the SimRel aggregation? (In reply to comment #14) > I'll report more, once mirroring is done. Result from aggregation: even after disabling the "Equinox" repo both versions of platform are included. I'll re-run with completely removing the "Equinox" *contribution* from the aggregation. Second test: even with "Equinox" contribution completely removed, both versions of platform are mirrored. (yep, this is the kind of question that "Validate Aggregation" does not answer). (In reply to comment #16) > Second test: even with "Equinox" contribution completely removed, both versions > of platform are mirrored. (yep, this is the kind of question that "Validate > Aggregation" does not answer). Ah, I guess I needn't experiment further: given that even S-4.2M6-201203151300 contains platform_3.8.0 I can't even test aggregation with Eclipse but without platform_3.8.0. (In reply to comment #16) > Second test: even with "Equinox" contribution completely removed, both versions > of platform are mirrored. (yep, this is the kind of question that "Validate > Aggregation" does not answer). When I do trial and error similar to what you're doing now, I usually turn off mirroring, run the build, and then examine the generated content.jar. (In reply to comment #13) > Who makes the 3.8 platform/SDK available on input? Will the aggregation succeed > without it and yield a result where there are no duplicates? Yes, this is (basically) but subject of bug 370644. I suspect it has something to do with the way they build 3.8 first, then build 4.2 "on top of" that ... not sure if there is a fundamental problem of not being able to provide a "pure" repo ... or merely some errors in scripts to create/merge/mirror their content. (In reply to comment #18) > When I do trial and error similar to what you're doing now, I usually turn off > mirroring, run the build, and then examine the generated content.jar. So, for us dumb-users of b3: can we disable mirroring from the Aggregation Model Editor? How? Removing bug dependency, as I managed to workaround the "primary build" issue. For my own records: changes to be eventually reverted are: commit 1ff3f41682184143dce74e1933a5261a554dc2eb commit b1aa9ecd99f3997e215842572dfe4639d0e393fa Should we assume this bug to be obsolete by now? Or does b3 want to keep it open to investigate why the aggregation is influenced like this just be the presence of 'patch="true"' aka <changes>..</changes>? Yes, I think obsolete. Thomas can reopen if he wants to investigate, but I suspect this was a case showing where p2 is able to come up with a "non optimal" solution in some cases. Nothing to fix. No longer an issue in the staging repo. [Bookkeeping change only. Moving bugs to the new "home" of aggregator, CBI. No change to assignee for resolved and verified bugs.] |