Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 342345

Summary:	Conflict resolution for features with different filters
Product:	[Technology] CBI	Reporter:	Thomas Hallgren <thomas>
Component:	CBI p2 Repository Aggregator	Assignee:	Project Inbox <b3.aggregator-inbox>
Status:	RESOLVED FIXED	QA Contact:
Severity:	normal
Priority:	P3	CC:	Kenn.Hussey, michal.ruza, miles.daffin
Version:	unspecified
Target Milestone:	---
Hardware:	PC
OS:	Linux
Whiteboard:

Description Thomas Hallgren

2011-04-09 02:46:57 EDT

In some repositories (helios, indigo, etc) we find features that are filtered for specific environments. The b3 aggregator is unable to cope when multiple instances of such features are found and their filters differ.

Here's an example:

The first thing the engine does is to create an IU that requires everything to be aggregated. To do this, it iterates over all features in the source repositories. In the Helios composite, the feature "org.eclipse.linuxtools.valgrind.feature.group" is found three times. Normally, this wouldn't matter because we only generate one requirement anyway (a requirement without version) and defer to p2 to find the right one.

So what goes wrong? Well, as we have seen in earlier bugs, for features/bundles that has filters on them, it is imperative that a requirement has the same filter. If it doesn't, p2 will consider the requirement active although what it points to is not. Under normal circumstances, the b3 aggregator is smart enough to include such filters in the requirements that it generates. For this particular feature however, there is a problem. The instances that are found doesn't have the same filters. One has a filter that says "(|(osgi.os=linux)(osgi.os=macosx))", another just "(osgi.os=linux"). So which filter should be used?

At this point, the b3 aggregator prints an info message "More than one filter definition found on org.eclipse.linuxtools.valgrind.feature.group; using an empty filter".

For reference, have a look at RequirementUtils.java, line 68.

I think this is wrong. The b3 aggregator should either use the most restrictive filter (there are cases when this cannot be computed) or consider this a conflict right there and give up. It should never use an empty filter.

Comment 1 Thomas Hallgren

2011-04-09 05:54:38 EDT

I fixed this so that filters are logically merged. I got some help from Buckminster's LDAP filter logic. It is capable of normalizing such merges.

The fix was checked into trunk, rev 1454. The main change was in the engine package but since I now also use a Buckminster bundle, I also had to change the product, engine feature, and site projects.

The linuxtools.valgrind feature no longer poses a problem when this fix is in place. When resolving the Helios composite however, the epp.packages are included, and that revealed another problem for which I entered bug 342350.

Comment 2 David Williams

2016-09-16 15:58:50 EDT

[Bookkeeping change only. Moving bugs to the new "home" of aggregator, CBI.
No change to assignee for resolved and verified bugs.]