Re: [tycho-dev] p2 data flow

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

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