[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
See below.
> -----Original Message-----
> From: tycho-dev-bounces@xxxxxxxxxxx [mailto:tycho-dev-bounces@xxxxxxxxxxx]
> On Behalf Of Oberlies, Tobias
> Sent: Freitag, 21. Oktober 2011 17:59
> To: Tycho developers list
> Subject: Re: [tycho-dev] re, Deferring Dependency Resolution
>
> Igor Fedorenko wrote:
> > Second, I think it is important to discuss and agree how P2 metadata
> > gets generated and consumed through various build stages. This is
> > something I was saying for a long time and fundamental change to Tycho
> > dependency resolution seems like a good time for this.
>
> Right. At the moment we have a quite a zoo of producers, consumers, and
> data paths. In the end, I would like to have this reduced to the
> following:
>
> - The (external) target platform is a p2 repository view. ("external" as
> not coming from the reactor)
> - Each module produces a p2 repository view with the artifacts built in
> the module. The p2 metadata content will need to be produced first (before
> dependency-resolution), and the p2 artifact repository entries will follow
> in "package".
> - The p2 metadata produced by a module is used as seed to resolve the
> module's dependencies, which gives a list of artifacts to be fed into the
> build class path calculator (which can only work on a list of artifacts).
> As today, this could be the result of a slicer&projector, but this could
> also be changed.
> - Dependency resolution could be dropped for eclipse-repository and
> instead be replaced by something with more fine-graned transitivity
> control. In either case, the aggregation would be done by copying
> installable units and corresponding artifacts either from the resolved
> dependencies or directly from the target platform.
Actually, all this is logically not much different from what is done in Tycho today. The only differences are:
- Through a re-organization of the build steps (and the new, non-p2 based build order mechanism), the dependency-only publishing and the real publishing can be collapsed into one publishing step.
- Instead all reactor projects, only the previously built modules become part of the target platform of a module.
That's all. In particular the first change allows to get rid of a great deal of redundancy -> source bundles, bug 352081, ...
Tobias
