Community
Participate
Working Groups
Created attachment 182776 [details] aggregator files I managed to locally replay the build breakage from https://hudson.eclipse.org/hudson/view/Repository Aggregation/job/indigo.runAggregator/101/console It complains that the fragment org.eclipse.objectteams.otequinox.sunjvm cannot be found but it is there and the feature includes this fragment only for exact the same platforms for which its own filter is set. Note that in RL with p2 updating this works just fine. I will leave the repository with the affected Object Teams artifacts online at http://download.eclipse.org/objectteams/updates/aggregator-problem and I will attach the minimum aggregator model to showcase the failure. Loading these into the aggregator editor and invoking Verify Repository will show as the root cause for failure: Missing requirement for filter properties ~= $0: Object Teams Equinox Integration (Incubation) 0.8.0.201011091433 (org.eclipse.objectteams.otequinox.feature.group 0.8.0.201011091433) requires 'org.eclipse.objectteams.otequinox.sunjvm [0.8.0.201011091433]' but it could not be found
On the forum we discussed putting using a combined filter so that you only get one requirement in the generated meta-data. Does that make any difference? In curious what it is that is different with this particular contribution. It shouldn't be the only one using filtered fragments.
(In reply to comment #1) > On the forum we discussed putting using a combined filter so that you only get > one requirement in the generated meta-data. Does that make any difference? > > In curious what it is that is different with this particular contribution. It > shouldn't be the only one using filtered fragments. The version in http://download.eclipse.org/objectteams/updates/aggregator-problem is the one *with* combined filters, so if you look into content.jar!/content.xml you see: <required namespace='org.eclipse.equinox.p2.iu' name='org.eclipse.objectteams.otequinox.sunjvm' range='[0.8.0.201011091433,0.8.0.201011091433]'> <filter> (|(osgi.os=linux)(osgi.os=solaris)(osgi.os=win32)) </filter> </required> where previously we saw three individual requirements with different filters. Could it possibly be that order matters in this combined filter?? Compare the above to the fragment's filter: <filter> (|(ogsi.os=solaris)(osgi.os=linux)(osgi.os=win32)) </filter>
No, order doesn't matter. Comparison is done by an expression evaluator.
I think I found it. Take a very close look at this filter: (|(ogsi.os=solaris)(osgi.os=linux)(osgi.os=win32)) The first 'osgi' is spelled 'ogsi'.
(In reply to comment #4) > I think I found it. Take a very close look at this filter: > > (|(ogsi.os=solaris)(osgi.os=linux)(osgi.os=win32)) > > The first 'osgi' is spelled 'ogsi'. Thanks, yep, we had a typo in this for months/years, dunno. However, that means that throughout the whole tool chain there's lots of room for improved validation and error reporting. I'm re-opening this bug for the issue in the aggregator and changing the bug title accordingly (was: "Aggregator doesn't find fragment with platform filter"). As for the aggregator I'd hope for at least one of the following: A) report that "ogsi.os" is not a valid property for a platform filter B) change error from Missing requirement for filter properties ~= $0: Object Teams Equinox Integration (Incubation) 0.8.0.201011091433 (org.eclipse.objectteams.otequinox.feature.group 0.8.0.201011091433) requires 'org.eclipse.objectteams.otequinox.sunjvm [0.8.0.201011091433]' but it could not be found to s.t. like: required artifact 'org.eclipse.objectteams.otequinox.sunjvm [0.8.0.201011091433]' is not available for the platform 'osgi.os=solaris'
(In reply to comment #5) > A) report that "ogsi.os" is not a valid property for a platform filter > The problem is that this isn't a 'platform filter'. It's a generic filter mechanism used internally by p2 planner. There's no way for the aggregator to say which keys that can be used and which that can't. The LDAP filter you see today is there for backward compatibility. The implementation will use a fullblown P2QL expression that is evaluated against a special IU that the platform provides during planning. I do think this error is trapped in the manifest editor though, so I'm surprised you didn't see it there. > B) change error > ... Again, the aggregator doesn't know this. The messages it prints comes from the explanation provided by the p2 planner. There's not much we can do about that. If you feel that the p2 planner should provide better info, then please open a p2 bug for that.
(In reply to comment #6) > (In reply to comment #5) > > > A) report that "ogsi.os" is not a valid property for a platform filter > > > The problem is that this isn't a 'platform filter'. It's a generic filter > mechanism used internally by p2 planner. There's no way for the aggregator to > say which keys that can be used and which that can't. I see, so someone upstream discards the information that the filter was indeed a platform filter -- without checking. > I do think this error is trapped in the manifest editor though, so I'm > surprised you didn't see it there. I didn't see it because it isn't implemented :) See bug 329984. > > B) change error > > ... > > Again, the aggregator doesn't know this. The messages it prints comes from the > explanation provided by the p2 planner. There's not much we can do about that. > If you feel that the p2 planner should provide better info, then please open a > p2 bug for that. That's now bug 329985.
[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.]
