[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [tycho-dev] p2 data flow
- From: Igor Fedorenko <igor@xxxxxxxxxxxxxx>
- Date: Mon, 14 Nov 2011 13:59:22 -0500
- Delivered-to: firstname.lastname@example.org
- User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20111105 Thunderbird/8.0
I will try to find time to review you changes in next few days.
Btw, any particular reason this work happens on github and not at
eclipse? I guess it does not matter too much, but managing extra remote
is kinda tedious.
On 11-11-14 1:44 PM, Oberlies, Tobias wrote:
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
From: tycho-dev-bounces@xxxxxxxxxxx [mailto:tycho-dev-bounces@xxxxxxxxxxx]
On Behalf Of Igor Fedorenko
Sent: Dienstag, 25. Oktober 2011 16:53
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
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?).
tycho-dev mailing list