Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [tycho-dev] p2 data flow

Update: I've got the POC working, so you can have a look at the code here:

> -----Original Message-----
> From: tycho-dev-bounces@xxxxxxxxxxx [mailto:tycho-dev-bounces@xxxxxxxxxxx]
> On Behalf Of Igor Fedorenko
> Sent: Dienstag, 25. Oktober 2011 16:53
> To: tycho-dev@xxxxxxxxxxx
> Subject: Re: [tycho-dev] p2 data flow
> On 11-10-25 7:58 AM, Oberlies, Tobias wrote:
> >> 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.

It should be easy to implement a BuildOrderParticipant based on p2 publisher actions - but for now, I chose to read the metadata directly and generate the Imports and Exports to be matched directly. This wasn't hard either, because Tycho already has classes for parsing Eclipse metadata.

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

Without fine-grained build order control, the refactoring doesn't make much sense. So if no one else implements this, I may need to contribute it to Maven (or Tesla? - BTW, any news on this?). 


Back to the top