Re: [tycho-dev] re, Deferring Dependency Resolution

["Oberlies, Tobias" <tobias.oberlies@xxxxxxx>]

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.

> 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)
- 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".
- 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.
- 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?

Regards
Tobias