[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [tycho-dev] p2 data flow
|
On 11-10-25 7:58 AM, Oberlies, Tobias wrote:
- 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?
Not if the reactor build order has been determined so that everything
which may be needed is built& published first. This extra ordering
is something we don't need today, but it isn't hard to do either. The
POC does this quite well already.
If I understand you correctly, this is fundamentally not much different
from current "dependency-only" and "full" p2 metadata we use today. The
real difference is how the dependency metadata is used, i.e. full
dependency resolution upfront or reactor project interdependencies only.
Since Tycho has to support many dependency metadata source and formats
(bundle manifest, feature.xml, p2.inf, etc), I think it still makes
sense to convert all these various formats to something common before
calculating reactor build order... but this is largely an implementation
detail.
- 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?
Assuming that the contributing mojo squeezes in at the right place,
this should be easy to do. In eclipse-repository, this is in
principle possible today: the PublishCategoriesMojo and
PublishProductMojo are called sequentially, and they both contribute
p2 metadata.
I do not believe this is a reasonably assumption. Most likely there will
be no fine control over plugin execution order in maven in near-to-mid
future.
For source bundles, the difficult thing today is that they have to be
taken into account twice: in the "dependency-only" publishing step
and in the actual module build. After the refactoring, the publishing
will only be done once, and that step could be done in a non-core
mojo. If source bundles also need to have an effect on the module
build order, then either the core needs to support this, or an extra
build extension would be needed which contributes to the build
order.
Just as today, extending the module order logic can only done through
Maven extensions and a Plexus based extension mechanism, but the
extender could just skip this part and accept that his extension
(e.g. for source bundles) does not have an effect on the build order.
The build order implementations simply matches imports and exports of
the reactor projects, and if there is something unmatched, e.g. an
my.bundle.source import, the build order logic does nothing.
If for example source bundles do not take part in module ordering, it
must be detected if the build order was wrong later on, in order to
prevent that reactor dependencies are resolved from other sources.
This should be doable, and this is something that must be working
rock solid before we can integrate the new build order mechanism into
master. I would accept that the new mechanism is not as complete as
what we have today, but only if this does not lead to any hidden
errors.
Yes, I agree that it should be enough to analyze direct project
dependencies to determine reactor build order. In fact, this is how
Maven works for "plain" maven projects, i.e. it does not consider local
and/or remote repositories when it calculates reactor build order.
Will it be possible to mutate or replace module's metadata to
support .qualifier replacement and metadata filtering in general?
This will be as easy as squeezing in to the lifecycle in the right
place. So currently this doesn't work, but I anyway consider better
mojo order control in Maven as a prerequisite of the refactoring.
As I already mentioned, I do not believe there are immediate plans to
introduce plugin execution ordering in Maven core. So we either need to
find another way to support what we need in Tycho or need to start
working on how to extend Maven core.
--
Regards,
Igor
