|Re: [tycho-dev] re, Deferring Dependency Resolution|
On 11-10-21 11:59 AM, Oberlies, Tobias wrote:
Igor Fedorenko wrote:My biggest concern is integration with non-tycho maven plugins. Currently, we have reasonably good story about all/most Tycho dependencies being pushed back to MavenProject, and this is simply not possible from a tycho mojo. We really need to hook into Maven dependency resolution logic to do this right, but I am not even sure if maven provides required extension points.What stops us from injecting the resolved OSGi dependencies into the Maven model in one of the early lifecycle phases? Sure, if we only realize at that point that the module order is wrong, the build must fail - but AFAIK there are sufficient possibilities to tweak the build order (e.g. by simply specifying a working order in the aggregator) so that the users can work around this (probably) rare case. A limitation of injecting the dependencies in a mojo is that the users need to ensure that that mojo is executed whenever they call individual goals from the command line. For example dependency:tree wouldn't show anything meaningful unless the phase with the dependency inject mojo of Tycho has been executed. However, I don't think this will be a major problem. People will get used to it, and by that time they will have learned something about Tycho :-) With more things happening in the default lifecycle, there will be more inter-phase ordering problems, so the proposed changes will probably require a solution for this implemented in Maven.
MavenProject dependencies are reset between mojo executions, at least in some cases. This is necessary to allow different mojo execution require different dependency scopes (i.e. compile vs test). Multithreaded build support is another consideration here, although I have not thought much about it yet. In any case, whether dependency resolution happens in a mojo or in maven core is not terribly important. As long as resolver is a standalone component, we can hook it in maven core or call it from mojos directly.
Second, I think it is important to discuss and agree how P2 metadata gets generated and consumed through various build stages. This is something I was saying for a long time and fundamental change to Tycho dependency resolution seems like a good time for this.Right. At the moment we have a quite a zoo of producers, consumers, and data paths. In the end, I would like to have this reduced to the following: - The (external) target platform is a p2 repository view. ("external" as not coming from the reactor)
What is "p2 repository view"? Repository URL(s) and resolution constraints or something more elaborate?
- Each module produces a p2 repository view with the artifacts built in the module. The p2 metadata content will need to be produced first (before dependency-resolution), and the p2 artifact repository entries will follow in "package".
p2 UIs of all reactor modules will need to be produced before dependency resolution, right?
- The p2 metadata produced by a module is used as seed to resolve the module's dependencies, which gives a list of artifacts to be fed into the build class path calculator (which can only work on a list of artifacts). As today, this could be the result of a slicer&projector, but this could also be changed.
Will external components (i.e. other maven plugins) be able to contribute to module's p2 metadata? Will we still need sources bundle support hardcoded in the core? Will it be possible to mutate or replace module's metadata to support .qualifier replacement and metadata filtering in general?
- Dependency resolution could be dropped for eclipse-repository and instead be replaced by something with more fine-graned transitivity control. In either case, the aggregation would be done by copying installable units and corresponding artifacts either from the resolved dependencies or directly from the target platform. So, what do you think of this idea?
This feels like too big a change to to done as one huge refactoring. Is there a way to split the work in smaller pieces or it really has to be all-or-nothing? Also, given the planned scope of changes, I think that split of eclipse-repository and eclipse-product packaging types needs to happen before any of this work. -- Regards, Igor
Back to the top