Community
Participate
Working Groups
Some recent build failures for Helios SR1 RC2 are mysterious. Makes me suspect an b3 aggregator problem? In short, fails with Missing requirement: org.eclipse.linuxtools.callgraph 0.0.1.201009021239 requires 'package org.eclipse.zest.core.widgets 0.0.0' but it could not be found But, appears it should be found. In content.jar/xml, I see <unit id='org.eclipse.zest.core' version='1.2.0.v20100525-1225'> ... <provided namespace='java.package' name='org.eclipse.zest.core.widgets' version='0.0.0'/> I wonder if related to "patial IU" issues that were recently fixed? See bug 322465. Below is longer, more detailed analysis from Andrew Overholt: = = = = = I took a look at this aggregation problem. I don't see how it could be failing. In the log [1] I see that org.eclipse.zest.core_1.2.0.v20100525-1225 is being mirrored as a "partial IU" (don't know what that means). I looked at the GEF update site with the p2 director [2] and that IU is indeed present. I then grabbed it from their zip, expanded it [3], and can see that it does indeed export the package we are requiring: $ grep -A 2 Export-Package org.eclipse.zest.core/META-INF/MANIFEST.MF Export-Package: org.eclipse.zest.core.viewers,org.eclipse.zest.core.vi ewers.internal;x-internal:=true,org.eclipse.zest.core.widgets,org.ecl ipse.zest.core.widgets.internal;x-internal:=true So I'm stumped as to why this is failing :) FWIW it doesn't look like the GEF contribution changed from Helios GA. I also looked at org.eclipse.linuxtools.callgraph between what we contributed for Helios GA and what we contributed for this failing build and see no source code differences: $ svn diff \ svn://dev.eclipse.org/svnroot/technology/org.eclipse.linuxtools/systemtap/tags/R0_6_0/org.eclipse.linuxtools.callgraph \ svn://dev.eclipse.org/svnroot/technology/org.eclipse.linuxtools/systemtap/tags/R0_6_1/org.eclipse.linuxtools.callgraph $ echo $? 0 Andrew [1] https://build.eclipse.org/hudson/view/Repository%20Aggregation/job/helios.runAggregator/326/consoleFull [2] $ eclipse -nosplash -consolelog -application org.eclipse.equinox.p2.director \ -repository http://download.eclipse.org/tools/gef/updates/milestones/ \ -list | grep org.eclipse.zest.core org.eclipse.zest.core=1.1.0.v20090504-1850 org.eclipse.zest.core=1.2.0.v20100525-1225 org.eclipse.zest.core.source=1.1.0.v20090504-1850 org.eclipse.zest.core.source=1.2.0.v20100525-1225 [3] Grab: http://www.eclipse.org/gef/download.php?file=/tools/gef/downloads/drops/3.6.1/S201008312021/GEF-Update-3.6.1RC2.zip $ unzip -d gef361rc2 GEF-Update-3.6.1RC2.zip $ cd gef361rc2/plugins $ unpack200 -v org.eclipse.zest.core_1.2.0.v20100525-1225.jar.pack.gz \ org.eclipse.zest.core_1.2.0.v20100525-1225.jar $ unzip -d org.eclipse.zest.core org.eclipse.zest.core_1.2.0.v20100525-1225.jar
I'm surprised there's been no comment yet, so am moving to the more accurate "blocker" severity. I'm assuming (once builds get building again, and) when we re-enable 'linux tools', that it will still fail, and there's not much time left this week to fix it. b3 team ... are you all on holiday? gef team ... will you be moving (back) to providing the required "p2 repository" instead of update site (hence avoiding the "partial IU" issues?). Thanks,
Sorry Dave, I missed that this a suspected aggregator problem. The missing requirement is for a package which makes me suspect that there is no feature that includes the bundle. If there was, then the complaint would be for the missing bundle. I'm not sure if package requirements are greedy (i.e. will cause an install to happen). If they are not, then that would explain the error. The p2 planner doesn't find the bundle and doesn't feel inclined to install it. In any case, I think it's bad practice if the setup is dependent on package requirements only. There really should be a feature somewhere that stipulates that the bundle (and a specific version of the bundle) is required.
(In reply to comment #1) > gef team ... will you be moving (back) to providing the required "p2 > repository" instead of update site (hence avoiding the "partial IU" issues?). As I said in Bug 322465 , our GEF build has not changed in a few years and I am not interested in changing for Helios SRx.
Thanks for the comments, Thomas and Anthony. > The missing requirement is for a package which makes me suspect that there is > no feature that includes the bundle. If there was, then the complaint would be > for the missing bundle. I'm not sure if package requirements are greedy (i.e. > will cause an install to happen). If they are not, then that would explain the > error. The p2 planner doesn't find the bundle and doesn't feel inclined to > install it. > > In any case, I think it's bad practice if the setup is dependent on package > requirements only. There really should be a feature somewhere that stipulates > that the bundle (and a specific version of the bundle) is required. Ok ... that is a level of advice I haven't heard before, and seems to contradict some advice about minimizing feature specifications and "let bundles do the work". But, perhaps that's only for "require bundle" cases. Where is ... or where should ... this be documented? This versioning document has a little of this kind of advice ... not sure if that's the best place? http://wiki.eclipse.org/index.php/Version_Numbering#To_require_features_or_to_require_bundles But that at least gives an option to the LinuxTools team to solve the problem ... to make a change in one of their high level features to required the gef/zest feature ... or to include the zest bundle? I've reenabled Linux Tools contribution and it indeed did fail again as expected. LinuxTools team ... can you change your feature definition as implied above?
(In reply to comment #3) > (In reply to comment #1) > > gef team ... will you be moving (back) to providing the required "p2 > > repository" instead of update site (hence avoiding the "partial IU" issues?). > > As I said in Bug 322465 , our GEF build has not changed in a few years and I am > not interested in changing for Helios SRx. I've opened GEF bug 324870 to discuss this further.
(In reply to comment #4) > Ok ... that is a level of advice I haven't heard before, and seems to > contradict some advice about minimizing feature specifications and "let bundles > do the work". But, perhaps that's only for "require bundle" cases. The reason I bring this up is the debacle we had with features that used version ranges for inclusions fairly late in the 3.6 cycle. According to Jeff McAffer, such loose requirements are very bad since it makes it impossible to do a reliable revert of a feature to an earlier version. Bundles that resides in an install solely because a loose requirement brought them in (such as a package requirement) will give the same negative effect. In this case, some feature should install a specific version of the zest bundle. That particular feature should "include" the bundle. All other features should abide by the "let bundles do the work" advice and ideally, not mention the zest bundle at all. That said, I did some investigation. AFAICT, package requirements are indeed greedy so this is not the cause of the failure. The log from the failing build seems to be lost though. Do you think you could re-enable the contribution again so that I have something to look at?
(In reply to comment #6) > (In reply to comment #4) > > > That said, I did some investigation. AFAICT, package requirements are indeed > greedy so this is not the cause of the failure. The log from the failing build > seems to be lost though. Do you think you could re-enable the contribution > again so that I have something to look at? Yes, just did. https://build.eclipse.org/hudson/view/Repository%20Aggregation/job/helios.runAggregator/351/console
I've opened bug 324879 to discuss the larger issue of how to best specify "require package" dependencies at feature level. Thomas, are you familiar with the issues discussed on EPP lists lately involving the "unexpected presence of slf4j bundles that were being brought in by the resolver". I'm not sure if that was "pulling too much" or "not pulling enough"? But adding Pascal, in case related (and in case you are not familiar with that issue and bug fixes around that). I (we) are currently using the released version of Eclipse 3.6 to do the aggregation. Would we expect different behavior than if we had the p2 fix to be released in 3.6.1? It just sounds to me like it had something to do with "greediness" but I've no idea what. Thanks,
Apparently, the linuxtools feature in question always has had a 'require' on the zest feature, and recently made that more exact, but don't think that would normally be required, right? Thomas, when you said a feature should "include" the plugin and not just rely on "require package" you didn't mean more than that .. did you? They currently have 21 <requires> 22 <import plugin="org.eclipse.ui"/> 23 <import plugin="org.eclipse.core.runtime"/> 24 <import plugin="org.eclipse.cdt.core"/> 25 <import plugin="org.eclipse.cdt.debug.core"/> 26 <import plugin="org.eclipse.cdt.launch"/> 27 <import plugin="org.eclipse.cdt.ui"/> 28 <import plugin="org.eclipse.core.resources"/> 29 <import plugin="org.eclipse.debug.core"/> 30 <import plugin="org.eclipse.debug.ui"/> 31 <import plugin="org.eclipse.jface.text"/> 32 <import plugin="org.eclipse.ui.ide"/> 33 <import plugin="org.eclipse.ui.console"/> 34 <import plugin="org.eclipse.ui.editors"/> 35 <import plugin="org.eclipse.core.filesystem"/> 36 <import feature="org.eclipse.zest" version="1.2.0.v20100519-2050-678-8yE4F-8HAH4DFEF3447"/> 37 <import feature="org.eclipse.draw2d" version="3.6.0.v20100519-2050-45-7w3121163602336"/> 38 </requires>
As an experiment, I set up an aggregation that contains the linuxtools repository, only with the org.eclipse.linuxtools.callgraph feature together with the gef contribution, and only the org.eclipse.zest feature. Together with the platform contribution, that combination resolves and mirrors without problems. This tells me that there's nothing wrong with the "Partial UI" stuff. It does what it's supposed to. What I'm suspecting is that there are other requirements involved that somehow causes a conflict involving the zest.core bundle ant that the reported problem is a manifestation of that conflict. What other contributions are using zest? Do you know?
(In reply to comment #10) > > What other contributions are using zest? Do you know? I do not know ... My guess would be 4 or 6 others? I guess a search of content.xml at current maintentance repo contains the data, if it could be found. In your experiment, you were using exactly the 3.6.0 released version? Or a more recent, near 3.6.1 version to run the aggregation?
I was using the one published after fixing bug 322465. Your comment 21 in that bugzilla seems to suggest that you switched to that one too?
(In reply to comment #12) > I was using the one published after fixing bug 322465. Your comment 21 in that > bugzilla seems to suggest that you switched to that one too? Yes, I was using that version of the aggregator ... but I install it "into" Eclipse 3.6 SDK ... does the aggregator pull over all the exact p2 bundles it wants? Or use what ever is in SDK? I ask because I've heard there were p2 fixes related to greediness (of some sort) that were made after 3.6 to be included in 3.6.1. So, just checking if we where using same level of p2.
The aggregator I used is based on the released version of the platform, i.e. 3.6. No recent fixes to the platform was in effect.
(In reply to comment #14) > The aggregator I used is based on the released version of the platform, i.e. > 3.6. No recent fixes to the platform was in effect. Ok, so that confirms that. So what's next? Is there some way to change the order of processing (say, by hand editing of the b3aggr file? (Just to test, see if the failure happens else where). You know ... another realization I just had ... the linuxtools features have filters (I'd assume) to make them "linux specific". Could this be interacting somewhow with the parital IU constructions? Jeff, you might be able to work around the current situation by changing your bundle that currently "requires package" on the zest package, to simply "require bundle" on the whole zest bundle that needed. I wouldn't think that hurt anything, since, I'd think, that package could only come from that bundle, right? What's the next step here?
(In reply to comment #15) > (In reply to comment #14) > > The aggregator I used is based on the released version of the platform, i.e. > > 3.6. No recent fixes to the platform was in effect. > > Ok, so that confirms that. So what's next? > > Is there some way to change the order of processing (say, by hand editing of > the b3aggr file? (Just to test, see if the failure happens else where). > > You know ... another realization I just had ... the linuxtools features have > filters (I'd assume) to make them "linux specific". Could this be interacting > somewhow with the parital IU constructions? > > Jeff, you might be able to work around the current situation by changing your > bundle that currently "requires package" on the zest package, to simply > "require bundle" on the whole zest bundle that needed. I wouldn't think that > hurt anything, since, I'd think, that package could only come from that bundle, > right? > Correct, that's what I came up with. The plug-in in question was not requiring the org.eclipse.zest.core plug-in but was instead importing package org.eclipse.zest.widgets in the Manifest. I've never used this and have always just required the plugins I needed. Perhaps the developer had a problem with the package moving between plugins. I have required org.eclipse.zest with a specific minimum version and hopefully this will solve the problem. The build has completed and I am about to copy the contents and update the b3aggrcon file.
Jeff's work-around seems to have worked (well, the aggregation build was successful at least ... no idea if his code still runs :) So what to do here? I'd like to close this blocking bug as "fixed" even though something still seems amiss to me. Based on Thomas's experiment in comment #10, the basic stuff with partial IUs works ok, but, obviously, something goes wrong in the larger build, like there's some interaction somewhere. I'll leave it up to Thomas if he wants to open an aggregator bug to continue to investigate this issue. Plus, GEF still needs to fix their repo (bug 324870) and we still need to improve our documented "advice" on how to include/require bundles and packages (bug 324879) but there's other bugs open for those two issues, so we'll track/follow them there.
