Community
Participate
Working Groups
The indigo repository for M3 (indigo/201011120900) only includes one version of org.eclipse.jdt.core, whereas the features listed in the repo require two versions. Indeed org.eclipse.jdt.feature.group requires org.eclipse.jdt.core 3.7.0.v_B22, and org.eclipse.objectteams.otdt.core.patch.feature.group requires 3.7.0.v_OTDT_r080_201011100445. I suppose that the problem is caused by the fact that the object team feature is a patch and that the aggregator does a complete dependency resolution which takes the original jdt.core out of the result.
When you say "it is not there in the repo" ... what makes you think so? Granted it is not on the file system in that subdirectory, but internally we "point to" the artifacts from the Eclipse platform, at /eclipse/updates/3.7milestones/S-3.7M3-201010281441 I've glanced at content.jar, and it does seem to be "provided", and other links and meta data appears correct (from a 5 minute glance). I could easily be missing something ... but, the 3.7.0.v_B22 version was included (correctly) with the JEE EPP package as as far as I know, that package build simply pulls features from the repo. That EPP package build does use "staging" though ... could something be going wrong when using the composite of all three milestone repositories under "releases"? I've not tried yet with p2 APIs. I assume that's what you mean when you say "its not there" ... but, thought I'd ask first. Thanks,
Hi Pascal, I just tried the following: Install the CPP M3 package and try to install "Eclipse Java Development Tools" from the Indigo repo. Here's what I get: Cannot complete the install because one or more required items could not be found. Software being installed: Eclipse Java Development Tools 3.7.0.v20100824-0800-7z8dFb7FMTfEQ4wDz0DJlHYd9H15 (org.eclipse.jdt.feature.group 3.7.0.v20100824-0800-7z8dFb7FMTfEQ4wDz0DJlHYd9H15) Missing requirement: Eclipse Java Development Tools 3.7.0.v20100824-0800-7z8dFb7FMTfEQ4wDz0DJlHYd9H15 (org.eclipse.jdt.feature.group 3.7.0.v20100824-0800-7z8dFb7FMTfEQ4wDz0DJlHYd9H15) requires 'org.eclipse.jdt.core [3.7.0.v_B22]' but it could not be found this seems to confirm what you were seeing. As an aside: it would have been cool, if our version would have been pulled in instead, because it *should* be 100% compatible and a big number of testers would have been welcomed for Object Teams. But I understand that the feature-to-plugin inclusion intentionally allows no version range matching. Sorry for the trouble.
BTW, there is a workaround for my scenario from comment 2: Install both "Eclipse Java Development Tools" and "Object Teams Development Tooling (Incubation)" at the same time :)
I can reproduce the issue. I did so by just starting with Eclipse Platform, and then trying to install Java. Both from p2 UI in workbench, plus using the directory app, from normal /releases/indigo and /releases/staging ... all with same failure, but using the original repo at http://download.eclipse.org/eclipse/updates/3.7milestones/S-3.7M3-201010281441 works just fine. CC'ing Markus. Is there some obvious reason this problem wasn't seen in the EPP Package builds? I would have thought it would catch problems like this. I admit I'm not sure where the problem actually is. I didn't see anything obvious in the content.jar/xml or artifacts.jar/xml.
And, before I forget ... there seems to be a "process" problem here. I can't imagine we can ever have people releasing "patched" versions of other project's plugins -- no matter how compatible it *should* be and no matter how much those projects would like a lot of testers. One solution, to me, is to "pull" the object team contribution for M3. What's the long term plan?
(In reply to comment #0) > I suppose that the problem is caused by the fact that the object team feature > is a patch and that the aggregator does a complete dependency resolution which > takes the original jdt.core out of the result. The aggregator is designed to handle this. It's supposed to detect patches and do extra resolution without them applied in order to get both the patched version and the unpatched version of each included patch in the final result. Obviously that doesn't work in this case.
> And, before I forget ... there seems to be a "process" problem here. I can't > imagine we can ever have people releasing "patched" versions of other > project's plugins I agree. It's an offense against the original project and lets that project look bad without having done anything. This should be prohibited even for an incubator project.
Created attachment 183185 [details] diff for right now, omitting object team's contribution To explore the possibility of a "quick fix" that simply omitted the object team contribution, I did an aggregation build just now, and besides object team's contribution, the only other thing that changed was PTP's contribution, being a few days later. (There was one change I didn't recognize ... org.eclipse.rephraserengine ... is that a mis-named bundle? belonging to ptp?). And I confirmed that using /releases/staging, the JDT core gets installed as expected (tested with the p2 director). So ... is this approach a viable emergency fix?
What exactly is patched in JDT Core? Can we (JDT Core) no longer be sure to investigate "our" bugs but bugs in patched JDT Core code? If so, we might refuse any support/help on any bug that's reported against a non-official version.
Adding Beth and Greg from PTP project to CC list. Can you comment on differences in PTP contribution, if we need to use a "rebuild" (the current /releases/staging) to have a quick fix for this bug, and an M3a repository? I don't think PTP (or object team code) is used in any EPP packages ... right? ... so, as far as I know, not much harm in using a different PTP build ... unless there were big differences? Would you prefer to "revert" PTP to match exactly what was delivered in M3?
I think it's needless to say but it's important for the record. it's the freedom of Open Source that nothing can be prohibited. Having said that, I suggest something similar to the API rules for the train. (A) We need documentation which explicitly explain what has been patched. This should be Bugzillas with the patches attached. (B) We need Bugzillas opened against the patched project in order to discuss the necessary API/extensibility changes in order to get rid of the patch. (C) The patched project must respond to (B) within a reasonable time with a proposed road-map towards implementing the necessary changes. (D) The patch producers must work together with the patched project in order to implement the necessary changes. (E) If the changes can't be implemented in time an approval must be requested from the AC. The AC will review and discuss the changes in detail.
Opend bug 330312 to further discuss the process issue David mentioned.
(In reply to comment #11) > I think it's needless to say but it's important for the record. it's the > freedom of Open Source that nothing can be prohibited. Well it depends on what level. Yes, you can take the code and doe something else but as soon as you modify the code you are obliged by the EPL to contribute that code back. Also, the project code is protected in the sense that only committers can modify the source of a project. In addition the train has rules which must be followed. So, you see, even in Open Source some things are prohibited and replacing the code of a project in the official repository is definitely something that belongs into that category.
(In reply to comment #13) > ... replacing the code of a project in the official repository > is definitely something that belongs into that category. I don't think the intention is to replace a project in the repository. The intended effect is to provide an additional bundle that will be installed when the patch is in effect, i.e. only when installing the feature provided by object team's contribution. Personally, I see no problem with that (other than of course, an apparent bug in the aggregator). Some projects are harder then others to influence. For valid reasons I'm sure (see bug 36939 comment 62 - bug is still open), but it would be sad if that blocks new and cool things from participating in the release. I'm not saying that patches should be allowed, rather that there should be a balance between "throw them out, they do bad things" and "please jdt.core, help these guys out a.s.a.p., you risk blocking their participation".
(In reply to comment #1) > missing something ... but, the 3.7.0.v_B22 version was included (correctly) > with the JEE EPP package as as far as I know, that package build simply pulls > features from the repo. > > That EPP package build does use "staging" though ... could something be going > wrong when using the composite of all three milestone repositories under > "releases"? EPP uses the following p2 repositories /eclipse/updates/3.7milestones/ + /releases/staging/ + EPP-repository in this particular order as artifact repositories *and* as metadata repositories. (From time to time it was necessary to limit the EPP build to a single sub-repository of these composite repositories in order to track down dependency problems, but this was not necessary in the Indigo build or in any other release builds.) (In reply to comment #4) > CC'ing Markus. Is there some obvious reason this problem wasn't seen in the EPP > Package builds? I would have thought it would catch problems like this. After looking into this for more than 5 minutes, the results can be explained. So far I don't see any necessity to change anything in EPP, but even that could be discussed. The EPP packages define a dependency to the org.eclipse.jdt feature group, they are not aware of any Object Teams contribution. This feature group - and I think this is important to note - defines an exact dependency to name='org.eclipse.jdt.core' range='[3.7.0.v_B22,3.7.0.v_B22]' which is not provided in the p2 metadata (content.jar) in releases/indigo/201011120900 but in the p2 metadata (content.jar). That's the reason why people are unable to install JDT from there. EPP uses the p2 metadata from eclipse/updates/3.7milestones/S-3.7M3-201010281441 and therefore had no problems to resolve the dependency. I think that (a) the artifact of the org.eclipse.jdt feature group is missing in releases/indigo/201011120900/aggregate/features (b) the p2 metadata in releases/indigo/201011120900 should contain the data for the both OSGi bundles org.eclipse.jdt.core (c) we would not have seen this problem if the p2 repository eclipse/updates/3.7 (that is defined in all downloads) would exist and point to an Eclipse milestone repository (In reply to comment #10) > I don't think PTP (or object team code) is used in any EPP packages ... right? I can affirm.
(In reply to comment #14) > (In reply to comment #13) > > ... replacing the code of a project in the official repository > > is definitely something that belongs into that category. > > I don't think the intention is to replace a project in the repository. The > intended effect is to provide an additional bundle that will be installed when > the patch is in effect, i.e. only when installing the feature provided by > object team's contribution. Personally, I see no problem with that (other than > of course, an apparent bug in the aggregator). I can confirm that of course Object Teams never intended to replace a single bit *in the repository*. All happens when a user chooses to install the Object Teams Development Tooling. On that issue I keep inviting people to participate on bug 316702 :) I hope the issue with the repositories can be sorted out on a technical level. Please let me know if I can help investigate the technical side of how to provide both versions of jdt.core within the Indigo repository. Concerns regarding the process dimension of this issue I'm commenting on bug 330312.
I've prepared an M3a repository at .../releases/indigo/201011170900/ to replace the M3 repository .../releases/indigo/201011120900/ With regrets to the ObjectTeam project, it has their contribution removed for M3. Apparently the only other project that has changed anything since M3 is PTP. I have not heard from them yet if they'd prefer to go with the (slightly?) new content or if they'd prefer to revert, but unless I do soon, we'll go with the 1117 repo, and I will disconnect the 1112 content from the .../releases/indigo composite repository. I have promoted the 1117 repo to "downloads" now, to give is some time to replicate to mirrors, and will make the official switch in the composite repo at approximately 9 am on 11/17 (Eastern) ... unless I hear objections from PTP project, that they need to revert. I'll also announce this on cross-project list, so others have at least some notice the M3 repo will be changing soon. While this particular "patch feature" has uncovered a bug in the b3 aggregator (I'm assuming) -- and that does need to be fixed -- the function should be for projects to provide their own patch features, not for other projects to dictate replacements, which I will also document more fully in other discussion threads.
FYI, I've opened an enhancement request for EPP packager at https://bugs.eclipse.org/bugs/show_bug.cgi?id=330393 While I don't think the EPP packager did anything "wrong", it'd be nice if it could serve as an early test of repo integrity.
(In reply to comment #10) > Adding Beth and Greg from PTP project to CC list. Can you comment on > differences in PTP contribution, if we need to use a "rebuild" (the current > /releases/staging) to have a quick fix for this bug, and an M3a repository? I > don't think PTP (or object team code) is used in any EPP packages ... right? > ... so, as far as I know, not much harm in using a different PTP build ... > unless there were big differences? Would you prefer to "revert" PTP to match > exactly what was delivered in M3? There are differences, but we don't have a problem if you rebuild with the current version. Please go ahead. The org.eclipse.rephraserengine plugins are part of the photran project.
I'll try and fix the aggregator problem.
The problem was that the aggregator used the wrong source when querying for IU's that the patch was applicable to. Instead of using the result that was produced in the planner when making the grand plan, it used the original sources. As a result, the patch in question was applicable to two versions of the jdt feature. In the next step, the aggregator used the planner to install both versions and of course, ran into a conflict. This is now fixed so that the source when querying for applicability is the result of the grand plan. This source will never contain duplicates. The original source is of course still used when doing the second plan that involves the unpatched versions of the patched IU's. The fix is now in trunk, rev 1404. I will start a new build shortly.
The new aggregator is now available at http://download.eclipse.org/modeling/emft/b3/updates-3.7milestones/ and the headless product is at: http://download.eclipse.org/modeling/emft/b3/headless-3.7milestones/ so the aggregator should no longer be an obstruction for Object Teams. I hope the other issues will be resolved quickly and that the contribution is re-enabled soon.
(In reply to comment #22) > [...] > so the aggregator should no longer be an obstruction for Object Teams. I hope > the other issues will be resolved quickly and that the contribution is > re-enabled soon. Thanks, Thomas According to bug 330312 the rules are set that patches are not OK for the release train. Details regarding a solution of Object Teams will be discussed in bug 330534 (plus additional information that I will link to that bug). Anyway it's good to know that the original bug no longer stands in our way should we be ready to renew a request for an exception from said rule.
(In reply to comment #22) > The new aggregator is now available at > > http://download.eclipse.org/modeling/emft/b3/updates-3.7milestones/ > > and the headless product is at: > > http://download.eclipse.org/modeling/emft/b3/headless-3.7milestones/ > Just to document it, your intent is we move to 3.7 M3 now? We have been running on 3.6. And those 3.7 milestones do not install on 3.6. Normally, since this is a production task, we should use only released platforms, IMHO ... but, I'll proceed to do the extra work to move to a different level of the platform in case you are saying that is required for some reason.
(In reply to comment #24) > Just to document it, your intent is we move to 3.7 M3 now? We have been running > on 3.6. And those 3.7 milestones do not install on 3.6. Bummer. We need to fork and give you a proper 3.6 maintenance release.
(In reply to comment #25) > (In reply to comment #24) > > Just to document it, your intent is we move to 3.7 M3 now? We have been running > > on 3.6. And those 3.7 milestones do not install on 3.6. > > Bummer. We need to fork and give you a proper 3.6 maintenance release. Maybe I'm doing something wrong with my "quick move" to 37 M3, but doesn't seem to install there either: [exec] Installing org.eclipse.b3.aggregator.engine.feature.feature.group 0.1.0.r01404. [exec] Cannot complete the install because of a conflicting dependency. [exec] Software being installed: b3 Aggregator Engine (Incubation) 0.1.0.r01404 (org.eclipse.b3.aggregator.engine.feature.feature.group 0.1.0.r01404) [exec] Installation failed. [exec] Software currently installed: Eclipse SDK 3.7.0.I20101028-1441 (org.eclipse.sdk.ide 3.7.0.I20101028-1441) [exec] Only one of the following can be installed at once: [exec] p2 query language 2.0.100.v20101011-2100 (org.eclipse.equinox.p2.ql 2.0.100.v20101011-2100) [exec] p2 query language 2.0.0.v20100503a (org.eclipse.equinox.p2.ql 2.0.0.v20100503a) [exec] Cannot satisfy dependency: [exec] From: b3 Aggregator Engine (Incubation) 0.1.0.r01404 (org.eclipse.b3.aggregator.engine.feature.feature.group 0.1.0.r01404) [exec] To: org.eclipse.equinox.p2.ql [2.0.0.v20100503a] [exec] Cannot satisfy dependency: [exec] From: Equinox p2 Provisioning 2.0.0.v20100503-897OFx-FdHjO2NkE10Uc8KQ (org.eclipse.equinox.p2.user.ui.feature.group 2.0.0.v20100503-897OFx-FdHjO2NkE10Uc8KQ) [exec] To: org.eclipse.equinox.p2.ql [2.0.100.v20101011-2100] [exec] Cannot satisfy dependency: [exec] From: Eclipse SDK 3.7.0.I20101028-1441 (org.eclipse.sdk.ide 3.7.0.I20101028-1441) [exec] To: org.eclipse.equinox.p2.user.ui.feature.group [2.0.0.v20100503-897OFx-FdHjO2NkE10Uc8KQ]
I've tried to install from http://download.eclipse.org/modeling/emft/b3/headless-3.7milestones/ on M3, M2a, M1, 3.6.1 as well as the original 3.6 and each case has some failure (different conflict in each case). So ... not sure how you build headless-3.7milestones but let's say this bug isn't fixed until I can install it :) I've reverted to using 3.6.1 SDK and aggregator repo at http://download.eclipse.org/modeling/emft/b3/headless-3.6/ Just let me know when a new aggregator is ready, preferably for 3.6.1 SDK. I was hoping to re-enable the object team contribution, as a small test of the fix ... assuming the object team contribution is still as it was.
(In reply to comment #27) > I was hoping to re-enable the object team contribution, as a small test of the > fix ... assuming the object team contribution is still as it was. I'm leaving the Object Teams contribution untouched until M4. Please let me know if I can help test/analyze/fix anything.
A new aggregator is now available at: http://download.eclipse.org/modeling/emft/b3/updates-3.6 http://download.eclipse.org/modeling/emft/b3/headless-3.6 Thanks Michal, for putting it together. Apparently that wasn't trivial because of bug 327234.
(In reply to comment #27) > I was hoping to re-enable the object team contribution, as a small test of the > fix ... assuming the object team contribution is still as it was. Whenever you want to do that experiment you could either re-enable the OT contribution as it was for M3, or change the OT repo to http://download.eclipse.org/objectteams/updates/bug330534 which prevents the JDT/Core variant from being installed unless explicitly requested. Both repos are compatible with SDK M3.
(In reply to comment #29) > A new aggregator is now available at: > > http://download.eclipse.org/modeling/emft/b3/updates-3.6 > http://download.eclipse.org/modeling/emft/b3/headless-3.6 > > Thanks Michal, for putting it together. Apparently that wasn't trivial because > of bug 327234. Thanks for the fix! I've installed it, ran the aggregation build (with object team contribution enabled), promoted result to staging, and from there could use the director to install jdt feature.group and did end up with org.eclipse.jdt.core_3.7.0.v_B22 It goes without saying, this was all a quick test ... just saying the aggregator is fixed. Thanks again!
[Bookkeeping change only. Moving bugs to the new "home" of aggregator, CBI. No change to assignee for resolved and verified bugs.]
