[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [tycho-dev] p2 data flow
- From: "Oberlies, Tobias" <tobias.oberlies@xxxxxxx>
- Date: Mon, 14 Nov 2011 19:44:06 +0100
- Accept-language: en-US, de-DE
- Acceptlanguage: en-US, de-DE
- Delivered-to: firstname.lastname@example.org
- Thread-index: AcyTJc+Djfdlxre6R3yws9Ur24pP3wP1oFFw
- Thread-topic: [tycho-dev] p2 data flow
Update: I've got the POC working, so you can have a look at the code here: https://github.com/oberlies/tycho/tree/bug353889_defer_resolution
> -----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
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
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?).