Re: [tycho-dev] p2 data flow

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

> -----Original Message-----
> From: tycho-dev-bounces@xxxxxxxxxxx [mailto:tycho-dev-bounces@xxxxxxxxxxx]
> On Behalf Of Igor Fedorenko
> Sent: Sonntag, 23. Oktober 2011 15:49
> To: tycho-dev@xxxxxxxxxxx
> Subject: Re: [tycho-dev] re, Deferring Dependency Resolution
> 
> On 11-10-21 11:59 AM, Oberlies, Tobias wrote:
> > Igor Fedorenko wrote:
> >> 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?

A list of IUs (e.g. as something implementing IMetadataRepository), and a list of IArtifactRepositories with contain the corresponding artifacts.


> > - 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.


> > - 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. 

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.


> 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.


Regards
Tobias