[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [tycho-dev] p2 data flow
|
Github is fine.
--
Regards,
Igor
On 11-11-15 3:29 AM, Oberlies, Tobias wrote:
Do we have a policy on branches in the main Git repository? I was
planning to do rebases and other force updates on the
bug353889_defer_resolution branch - but do we want to allow this in
the main repository? I have a small preference towards keeping
experimental changes out of the main repo - and github offers a
reasonable alternative.
Regards Tobias >
-----Original Message-----
From: tycho-dev-bounces@xxxxxxxxxxx [mailto:tycho-dev-bounces@xxxxxxxxxxx]
On Behalf Of Igor Fedorenko
Sent: Montag, 14. November 2011 19:59
To: tycho-dev@xxxxxxxxxxx
Subject: Re: [tycho-dev] p2 data flow
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.
--
Regards,
Igor
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
-----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?).
Regards
Tobias
_______________________________________________
tycho-dev mailing list
tycho-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/tycho-dev
_______________________________________________
tycho-dev mailing list
tycho-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/tycho-dev
_______________________________________________
tycho-dev mailing list
tycho-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/tycho-dev
