Community
Participate
Working Groups
Created attachment 172528 [details] ECF Aggregation There's a missing reference to org.eclipse.ecf.core.featurepatch.feature.jar in the http://download.eclipse.org/releases/helios repository. I tried to repeat a minimized process and it looks like the aggregator does not the right thing here. Steps to reproduce (use attached files): 1) Open helios.ecf.b3aggr 2) Run "Build" (it should not fail) 3) Open helios.ecf.test.b3aggr 4) Modify the repository location to whatever your real local path is 5) Run "Verify" You get an error: org.eclipse.ecf.core.featurepatch.feature.jar is missing (it is also obvious when browsing the repository manually). In addition to this, if you disable repository that is mapping "org.eclipse.equinox.p2.user.ui" feature (and leave the repository as a validation repository only), you get a different error (complaining that org.eclipse.equinox.p2.user.ui is missing). Perhaps this deserves a separate bug but I write it here for case that the problems are related to each other.
Created attachment 172529 [details] ECF Aggregation Test
Another observation is that no .build file requires the patch IU. So why is it included in Helios at all?
I think it would make sense in future to test Eclipse P2 repositories by trying to mirror them with the B3 Aggregator (set to verify of course). This would catch this type of issue and give greater confidence that the repos were of good quality.
What is the status of this issue? What can be done to fix it?
This is what the aggregator does today: 1. It computes a set of roots based on the given contributions. 2. It uses the p2 planner to define the set of IU's to be mapped based on #1. 3. It queries all sources to find any patches applicable to the result of #2. 4. It uses the p2 planner again, once for each patch found in #3 to create a new plan where the patch itself is excluded. 5. The mapped IU's of the new plans are added to the old set of IU's to be mapped. The result is a repository that contains everything needed, with or without the patch. So far so good. The problem is that the patch, although applicable to one of the mapped IU's, isn't really required by anyone. This means that the patch itself never takes part in any planning. Hence the requirement from the patch to it's feature.jar is never considered. The solution is to include patches only when they are required by some feature. This means that two things needs to be tweaked: Tweak #1. Between step #3 and step #4 above, the aggregator must make sure that the found patches are indeed required in the result that has been determined so far. This means that the collection 'unitsToAggregate' must include the patch when the 'getUnpatchedTransitiveScope()' method is called. If it doesn't, the patch should be excluded. This tweak will ensure that the resulting repository is consistent since only patches that are included in the original plan are considered. Tweak #2. For contributions where no features has been defined, we currently use all features (in VerificationFeatureAction). This must change so that IU's of type IInstallableUnitPatch are excluded. This tweak will make sure that only patches that are not requested by other features are included. I.e. the patch itself doesn't become a 'root'. The second tweak will also have the nice side-effect that the current Helios repository will be mappable without exclusion rules since no feature includes the culprit patch.
Fixed and uploaded to http://download.eclipse.org/modeling/emft/b3/updates-3.7milestones
[Bookkeeping change only. Moving bugs to the new "home" of aggregator, CBI. No change to assignee for resolved and verified bugs.]