Bugzilla – Full Text Bug Listing
| Summary: | aggregator could be more forgiving of multiple singletons if resolution.devMode=true specified | ||
|---|---|---|---|
| Product: | [Technology] CBI | Reporter: | David Williams <david_williams> |
| Component: | CBI p2 Repository Aggregator | Assignee: | CBI Inbox <cbi-inbox> |
| Status: | CLOSED WONTFIX | QA Contact: | David Williams <david_williams> |
| Severity: | enhancement | ||
| Priority: | P3 | CC: | frederic.gurr, thomas |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Whiteboard: | |||
|
Description
David Williams
The aggregator uses the p2 planner to define the set of IU's to mirror. The p2 planner is not forgiving in any way. I could be wrong but it seems to me like the osgi.resolverMode controls how access restriction rules of exported packages are used at runtime and AFAICT, the PDE Build uses the resolution.devMode for the same purpose. They can be forgiving and let bundles resolve in the 'build state' even though they violate some access rules. I don't think they resolve even though requirements are unfulfilled (and I can't see how they could since that implies compiler errors). In any case, to my knowledge, the p2 planner supports neither option. What we could do, is to add some way of mirroring a repository verbatim. I.e. mirror 100% of it's IU's without any control whatsoever. Not sure if that's useful though. See also bug 330442 and bug 303178. Yes, from reading posts and blogs about resolution.devMode=true, I think it must do more than set osgi.resolverMode=development. (In reply to comment #2) > Yes, from reading posts and blogs about resolution.devMode=true, I think it > must do more than set osgi.resolverMode=development. And meant to say ... so, I've changed title to reflect that. But, I would agree ... this has relatively limited usefulness and should counted as "minor" enhancement request. > What we could do, is to add some way of mirroring a repository verbatim. I.e. > mirror 100% of it's IU's without any control whatsoever. Not sure if that's > useful though. Not sure if you mean this literally ... which sounds the same as p2 mirror operation? The one thing "extra" that the aggregator (normally) does is more checking on the pack.gz files, to verify they can be unpacked, etc. That is originally the reason I began playing with this idea ... see bug 364785 ... but, there are other ways of doing that using unpack200 and jarsigner -verify. So, feel free to leave open if you'd like to "track" ... or, close as "won't fix" if you think not worth considering further. I'm not aware of any option that will make the p2 planner allow multiple singletons, so this will be difficult to implement as something that happens in response to a property setting. The solution that the aggregator offers today is to create different validation sets. Conflicting singletons can be aggregated by moving them into separate validation sets. Doing it this way is a very conscious decision to force this inconsistency and it's also reflected in the aggregation model. (In reply to comment #3) > Not sure if you mean this literally ... which sounds the same as p2 mirror > operation? > It would be very similar to a p2 mirror operation with optional unpack validation. still intact. (In reply to comment #5) > (In reply to comment #3) > > Not sure if you mean this literally ... which sounds the same as p2 mirror > > operation? > > > It would be very similar to a p2 mirror operation with optional unpack > validation. still intact. I guess another advantage to having this "unchecked" case, would be if the aggregator could also, still, produce the side-by-side maven repo? I just thought of this with recent discussions on Orbit's mailing list: such as http://dev.eclipse.org/mhonarc/lists/orbit-dev/msg02371.html (In reply to comment #4) > The solution that the aggregator offers today is to create different validation > sets. Conflicting singletons can be aggregated by moving them into separate > validation sets. Doing it this way is a very conscious decision to force this > inconsistency and it's also reflected in the aggregation model. I'm assuming this is done on a feature-by-feature case? I'll have to look closer as "validation sets". (We used to "build" Orbit using different features when there were conflicting singletons ... until PDE builder was "fixed" to allow ... it was sort of complicate, especially for our simple "assembly" case, to have separate features just for "singleton collections". Thanks as always. [Bookkeeping change only. Moving bugs to the new "home" of aggregator, CBI.] If this issue is still relevant, please move it to https://github.com/eclipse-cbi/p2repo-aggregator/issues. |