[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
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
