Bugzilla – Full Text Bug Listing
| Summary: | 3.7milestones artifact repository linked from Juno repositories | ||
|---|---|---|---|
| Product: | Community | Reporter: | Markus Knauer <mknauer> |
| Component: | Cross-Project | Assignee: | David Williams <david_williams> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | david_williams, gunnar, igor, john.arthorne, kim.moir, pwebster, sbouchet |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | Other | ||
| OS: | other | ||
| Whiteboard: | |||
| Bug Depends on: | |||
| Bug Blocks: | 370644 | ||
This is coming from the equinox.b3aggrcon file. There, each feature has been disabled, but not the repositories. I've been assuming they'd be "fixed" soon and features re-enabled and repositories updated. In case that does not happen for M6 (for what ever reason ... are they not needed anymore?) ... then I will now (early for M6) disable the repositories and see if there's any obvious unintended side effects). Yes, there will be side effects, I think. So, Kim, please don't delete that old repo, at 'http://download.eclipse.org/eclipse/updates/3.7milestones/S-3.7RC5-201106131736'/> until at least after M6 is done or many installs from /releases/juno will start to fail :( What I've noticed so far, testing locally, is that some projects (apparently) depend on some of the "old" stuff from the platform, and they have been "getting it for free" by virtue of this repo being linked in the composite. For example, BIRT, depends on org.apache.jasper. org.eclipse.mtj.core depends on org.mortbay.jetty.server I'm not exactly sure how those projects build and get their Juno prereqs, that they would not have noticed ... but, from what I can tell, they still depend on the old stuff. So ... I'll announce on cross-project list, and give some early warning of "quick breakage" in M6 aggregation. I assume that BIRT builds using a target platform that contains the relevant jars from Orbit. They might just have forgotten to include them in the contribution to the common repo. That's why they are fetched from the Equinox repos. +1 for removing the repos from the aggregation. Just for clarification because it is only implicitly mentioned: Are we talking about removing this reference in the Juno M6 repository, or are we going to remove this reference in *all* old composite repositories beginning with Juno M1? My take on this: In order to have a 'clean' Juno repository we need to remove it from *all* old milestone repositories. (In reply to comment #4) > Just for clarification because it is only implicitly mentioned: Are we talking > about removing this reference in the Juno M6 repository, or are we going to > remove this reference in *all* old composite repositories beginning with Juno > M1? My take on this: In order to have a 'clean' Juno repository we need to > remove it from *all* old milestone repositories. My thought was just to remove it from the b3aggrcon file, as we build M6. We'll see how that goes. My preference would be to leave M5 and M4 alone, but then, likely, not provide M6 as a composite with M4 and M5 but M6 alone. Since removing it from M4 or M5 repos would "break" some projects installing, at all, I would prefer not to do that. ('m fairly sure this only effects "old" third party packages that people had been counting on being in the platform, but we'll know more once we start building M6. Status so far ... I disabled BIRT until they have time to react, and disabled just one feature of mjt (org.eclipse.mtj.examples). The next problem encountered might be more serious ... part of m2e (and others, I'm sure) depend on org.eclipse.equinox.p2.ui.discovery but I am not sure that is in the current 3.8 or 4.2 repositories ... so ... not sure if this was a change (doubt it) or if there is part of the "equinox build" that is missing? (In reply to comment #6) > Status so far ... I disabled BIRT until they have time to react, and disabled > just one feature of mjt (org.eclipse.mtj.examples). > > The next problem encountered might be more serious ... part of m2e (and others, > I'm sure) depend on org.eclipse.equinox.p2.ui.discovery but I am not sure that > is in the current 3.8 or 4.2 repositories ... so ... not sure if this was a > change (doubt it) or if there is part of the "equinox build" that is missing? I did check, and see that bundle in the SDK's distribution zip, so must be somewhere. Maybe there is another repo I (or someone) could add to the equinox.b3aggrcon file? org.eclipse.equinox.p2.ui.discovery is part of the Equinox build (In reply to comment #8) > org.eclipse.equinox.p2.ui.discovery is part of the Equinox build And ... my mistake (above) ... I do see it in 3.8milestones/S-3.8M5-201201251800 so let me monkey around with that ... not sure what "features and products" should be in that equinox.b3aggrcon file (that's why they were all disabled before) ... but ... I think we can limp a little further. Status update: putting in the 3.8 repo helped solve p2.ui.discovery problem ... but, of course, we are still at little "exposed" since someone in Juno might still be depending on some org.eclipse package in 3.8 but not in 4.2. We can partially check this with "duplicate version" report once I promote something to staging. But, I assume the goal is to have everything in one repo ... soon? .... by M6? I did have to disable all of mtj (just to document it) and had to disable linux tools, since birt was disabled. But think next run will finish green so we will be one step in the right direction. latest status: Lets see ... how can I put this gently ... the 4.2 M5 repo is a mess :) I am aware of some of the reasons (still building 3.8 first, etc.) but in the end [after hours and hours of debugging and aggregation build tweaking] the 4.2 M5 repo is missing some things (like p2 discovery) but has both 4.2 and 3.8 versions of other things ... such as the workbench! <unit id='org.eclipse.ui.workbench' version='3.103.0.v20120126-1500'> <unit id='org.eclipse.ui.workbench' version='3.8.0.v20120123-1720'> In an attempt to end up with only one version (latest) in /releases/staging, I've changed the aggregation build to no longer treat Equinox and Eclipse as "trusted repositories", so what we end up with in /releases/staging should be literally what is "pulled in" by someone, somewhere in their contributions, but a) we still end up with 3.8 and 3.103 version of workbench (and other duplicates) in /releases/staging. for current list, see http://build.eclipse.org/juno/simrel/reports/nonUniqueVersions.txt but b) as far as I can see, its not clear what is causing the "old" versions to be pulled in ... might be a subtly of the aggregator or of the 4.2M5 repo itself, rather than someone having "old" prereqs specified. It will need more investigation, to see if we can improve "staging" until we can get a more pure form of a 4.2 repo ... but, in the mean time, it is hard to know how accurate tests (or builds) against it would be, since the 4.2M5 repo itself contains some "3.8 content" (but, missing some, that would be common, such as p2 discovery). Its late. (In reply to comment #11) > > Its late. I meant to say, in case I sound grumpy, its late. :) I should point out the good news that at least we are no longer "pointing to" Indigo level stuff and I've heard from both MJT and BIRT teams and they expect fixes before too long, so thankfully the original reason for this bug (the 3.7 repo pointer) isn't that bad. The 3.8 workbench stuff is really a separate issue ... the investigation here just made that issue more apparent. Appreciate everyone's reports and patience. I'll close this bug as "fixed" since the "3.7 Indigo" issue has been resolved (though, some teams still reacting to that, the fundamental problem here has been fixed). The "new" issues with 4.2 repo not having all equinox bundles (and the aggregator seemingly not working as I expected) will be tracked in bug 370644. |
All Juno compositeArtifacts.jar files (M1...M5, staging) contain a link to two different Eclipse Platform repositories, e.g. <children size='3'> <child location='http://download.eclipse.org/eclipse/updates/3.7milestones/S-3.7RC5-201106131736'/> <child location='http://download.eclipse.org/eclipse/updates/4.2milestones/S-4.2M4-201112092100'/> <child location='aggregate'/> </children> I am sure there was a reason (?) to add the 3.7milestones/S-3.7RC5-201106131736 repository at the beginning, but it should be removed in Juno M6.