Community
Participate
Working Groups
I'm opening this as a continuation of issue raised in bug 315644. In brief, org.eclipse.emf.teneo.jpox.libraries is being included in helios aggregation, but no feature includes it. and no bundle requires it, directly. I suspect, somewhere, some bundle requires one of the packages that the bundle exports (which includes some very commonly imported ones, such as org.apache.commons.collections, log4j, etc.) and p2 encounters a need for that package, and (somehow) finds this bundle provides it so p2 pulls it in. But no one wants it. I know b3 aggregator has "exclusion rules" in general, but I'd guess we can't use those with old format .build files? Plus, to me, seems hard to provide exclusion rules for every (old) thing you wouldn't want. Is there some easier way to constrain aggregator? P2? Is this a bug? Or one of those wonderfully powerful features of p2?
The exclusion rules wouldn't help in this case since it works at feature level. It doesn't really affect what's available to the planner and it doesn't interfere with the planning at all. The planner does it's job. It comes up with a plan that will allow everything to be installed as one big coherent feature. That means that it considers the old unwanted plug-ins the best match. The only way to get rid of that is to convince it that something else is preferred. One way to do that is to let a feature have a hard requirement to another (preferred) bundle that exports the common packages. Apparently that is not the case today. A more advanced approach would be to express a negation that excludes the unwanted bundles from the plan. Today that could be done in a p2.inf file of a feature. I can see how that could become a future enhancement to the aggregator. We could add it as a negation requirement on the generated top level feature. At present I'm afraid I have no simple solution. Given that the next release is RC4, I'm a bit reluctant starting new experiments with the aggregator.
Thanks Thomas. I certainly agree with no experiments. This was noticed only because it was unsigned ... which by itself would not be "bad" ... the only bad thing would be if there was some combination of things (or "select all") that caused this to be installed ... which would probably not be what anyone would want. As a work around for Helios, is there any chance we could "post process" the repo, and use p2.remove task to remove 1 or 2 artifacts that are known to be incorrect? Or would that risk leaving the repo in an inconsistent/incomplete state?
(In reply to comment #2) > As a work around for Helios, is there any chance we could "post process" the > repo, and use p2.remove task to remove 1 or 2 artifacts that are known to be > incorrect? Or would that risk leaving the repo in an inconsistent/incomplete > state? I'm afraid that the answer is very likely yes. The planner does have a reason for the inclusion. If that reason is purely based on optional requirements, then it will be OK. If not, well, then there's a problem. The best fix is probably to go to the source. Would it be possible for the contributor to refrain from making the unwanted bundles available to the aggregation?
> > The best fix is probably to go to the source. Would it be possible for the > contributor to refrain from making the unwanted bundles available to the > aggregation? Would that be by removing it from the uber repo where it currently is? Maybe. (or, moving to some special "old" repo not linked in). Yet another case adding doubt to the proposition that "repos are forever", eh? :)
(In reply to comment #4) > Yet another case adding doubt to the proposition > that "repos are forever", eh? :) It shows that there's more then one truth. In some situations it's good to have historical data while in others, it really gets in the way. I think this needs to be discussed in more depth. We need to break things down to pros and cons for different use-cases and then make things available based on what we conclude. The current situation is not good.
I'm closing this as invalid since I don't see how we can improve the situation with the aggregator. Concrete proposals are welcome as separate enhancement requests.
[Bookkeeping change only. Moving bugs to the new "home" of aggregator, CBI. No change to assignee for resolved and verified bugs.]
