Community
Participate
Working Groups
I'm having some issues with the dependency resolution while bringing Gyrex into Indigo. Basically, b3 complains about missing dependencies although they are in the repository. When verifying locally I get a different error than reported by Hudson. I committed the gyrex.b3aggrcon for others to reproduce the problem. I also noted that I had to switch feature dependencies to "Compatible". The default (Greater or equal) did not produce the correct p2 version range. BTW, can someone point me to the special p2 instructions that prevent a feature from being installed into an IDE?
Moving to b3 for further comment.
Created attachment 184019 [details] screenshot of the error message
Created attachment 184020 [details] screenshot of the repo as shown in the b3 editor
(In reply to comment #0) > When verifying locally I get a different error than reported by Hudson. I > committed the gyrex.b3aggrcon for others to reproduce the problem. > What error do you get locally? > I also noted that I had to switch feature dependencies to "Compatible". The > default (Greater or equal) did not produce the correct p2 version range. > What did the incorrect version range look like? > BTW, can someone point me to the special p2 instructions that prevent a feature > from being installed into an IDE? You add a requirement in an p2.inf file: requires.1.namespace=A.PDE.Target.Platform requires.1.name=Cannot be installed into the IDE requires.1.range=0.0.0
(In reply to comment #5) > (In reply to comment #0) > > When verifying locally I get a different error than reported by Hudson. I > > committed the gyrex.b3aggrcon for others to reproduce the problem. > > > What error do you get locally? See the attached screenshots. I'll try a re-build soon with the feature-dependencies removed. > > I also noted that I had to switch feature dependencies to "Compatible". The > > default (Greater or equal) did not produce the correct p2 version range. > > > What did the incorrect version range look like? It looked like a direct version dependency.
(In reply to comment #6) > > What did the incorrect version range look like? > > It looked like a direct version dependency. OK. Just to make sure. An open ended range (i.e. >=) should look like this: 1.0.0 whereas a the corresponding direct version dependency will be: [1.0.0,1.0.0] You claim that by using the Greater or Equal, you get the latter?
(In reply to comment #7) > You claim that by using the Greater or Equal, you get the latter? Frankly, I think it was the first not the latter. I have no proof because I converted to "compatible" and it's now ok and even better for my case.
It seems that b3 is unable to resolve included dependencies within the same repository. Not sure what is going on. I just tried with a new build that has the feature dependencies removed from feature.xml files. The error that I get now when verifying the repository is: Gyrex Target Components (Incubation) 1.0.0.v20101129-1220-7L--F9kx82dfPt3af6wpIN9z0bVN (org.eclipse.gyrex.features.sdk.feature.group 1.0.0.v20101129-1220-7L--F9kx82dfPt3af6wpIN9z0bVN) requires 'org.eclipse.gyrex.features.kernel.feature.group [1.0.0.v20101124-1415-7A--F7RZHQHQQO28NrmW] However, when I look into the repo using the editor I can see the corresponding IU: org.eclipse.gyrex.features.kernel.feature.group / 1.0.0.v20101124-1415-7A--F7RZHQHQQO28NrmW (Gyrex Kernel (Incubation)) Could it be some underlying issue that is preventing IU 'rg.eclipse.gyrex.features.kernel.feature.group' from being resolved properly?
I think, maybe, the issue has to do with platform filters. Current error msg is Missing requirement: org.eclipse.gyrex.features.sdk.feature.group 1.0.0.v20101124-1920-7L--F9kw82d1TXvQlFnX0fCz-G1k requires 'org.eclipse.gyrex.features.kernel.source.feature.group [1.0.0.v20101124-1415-7A--F7RZHQHQQO-8OlhR]' but it could not be found By looking in the content.xml file, I see that the sdk feature has no platform filter, which is the same as "any", but the source feature has a platform filter of 7303 <filter> 7304 (&(|(osgi.arch=x86)(osgi.arch=x86_64))(|(osgi.os=linux)(osgi.os=macosx)(osgi.os=win32))(|(osgi.ws=cocoa)(osgi.ws=gtk)(osgi.ws=win32))) 7305 </filter> So, I think what happens, in aggregator, is that when looking to aggregate the sdk feature, it is looking for dependencies that match versions constraints, and platform constraints, so its needs a feature that matches "any", basically. How/why does that source feature have platform constraints? I think they need to be removed ... or some added to sdk feature.
(In reply to comment #10) > I think, maybe, the issue has to do with platform filters. > I meant to add ... this doesn't show up during an "install", because then p2 is looking for one and only one platform, so they all do match with that one platform. If this is indeed the issue, can the error msg be improved? I seem to recall this having happened a couple of times in the past.
(In reply to comment #11) > If this is indeed the issue, can the error msg be improved? I seem to recall > this having happened a couple of times in the past. The aggregator doesn't know the reason behind a resolution failure. We leave all that to the p2 planner. We use it's "Explanation support" feature to extract information about failures. Unfortunately, the explanation is not explicit down to filter details. I suggest you add an enhancement request for more elaborate explanations to equinox/p2. The filter will be a problem unless all requirements pointing to the filtered IU has the same filter as the IU itself but the problem will only manifest itself in environments where the filter evaluates to false. The Helios aggregation does include such environments. So the key question is, what does the requirement for the source feature look like?
> > BTW, can someone point me to the special p2 instructions that prevent a feature > from being installed into an IDE? As far as I know (not that I would ... I haven't followed issue closely) the special magic is (still) to use a dependency on a special A.PDE.Target.Platform. You might read through bug 313873 and the bugs it points too ... but easiest way to get it working is to take a look at how RAP runtime does it, and following their example.
(In reply to comment #13) > ... You might read through bug 313873 and the bugs it points > too ... but easiest way to get it working is to take a look at how RAP runtime > does it, and following their example. Or just follow my example from comment 5 ;-)
(In reply to comment #14) > (In reply to comment #13) > > > ... You might read through bug 313873 and the bugs it points > > too ... but easiest way to get it working is to take a look at how RAP runtime > > does it, and following their example. > > Or just follow my example from comment 5 ;-) Oh, sorry ... too much speed reading after my holiday. :)
> > I suggest you add an enhancement request for more elaborate explanations to > equinox/p2. > I have opened enhancement request bug 331403. Thanks,
(In reply to comment #10) > I think, maybe, the issue has to do with platform filters. Good catch! Thanks David. The repo now validates fine in my local environment. Let's see if it now builds correctly on Hudson as well. I'm closing this as WORKSFORME since a different issue was opened for the p2 enhancements.
[Bookkeeping change only. Moving bugs to the new "home" of aggregator, CBI. Made no changes to assignee's for closed bugs, even though some were old inbox.]
