[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [tycho-dev] [discuss] tycho repository layout and metadata format
- From: "Oberlies, Tobias" <tobias.oberlies@xxxxxxx>
- Date: Thu, 16 Jun 2011 11:36:56 +0200
- Accept-language: en-US, de-DE
- Acceptlanguage: en-US, de-DE
- Delivered-to: email@example.com
- Thread-index: Acwga6grokhuRNH7TDOwy9CAlGCrdALm0hBA
- Thread-topic: [tycho-dev] [discuss] tycho repository layout and metadata format
The common approach in p2 for defining an immutable set of IUs is to take a set of features and everything that is included in these features. In p2, this translates to a PermissiveSlicer with considerOnlyStrictDependency=true. In target files, the same is achieved with location/@includeMode=slicer. A set of IUs defined in this way is immutable under additions.
I agree that reproducibility can that only be achieved with an explicit white list in the sources, e.g. through features, or possibly other immutable IU set descriptors. I don't think that using something non-deterministic and then add constraints won't work.
And since you were discussing about making small changes to the target platform: this is easily possible with feature patches. By adding a feature patch to a target platform defined through features, you can replace individual bundles by patched versions.
@Igor: As for the more general repository format discussion, I am wondering if you know our Nexus Unzip Plugin. Except for implementation optimizations, I believe that it is conceptionally all that we need to have Nexus natively serve the same artifacts as p2 and Maven repository.
> -----Original Message-----
> From: tycho-dev-bounces@xxxxxxxxxxx [mailto:tycho-dev-bounces@xxxxxxxxxxx]
> On Behalf Of Igor Fedorenko
> Sent: 01 June 2011 16:53
> To: tycho-dev@xxxxxxxxxxx
> Subject: Re: [tycho-dev] [discuss] tycho repository layout and metadata
> We need to know if *future* repository content changes can affect
> resolution results. This I believe boils down to being able to tell if
> IMatchExpression<IInstallableUnit> is guaranteed to match one and only
> one installable unit or not. And even this may not be enough to handle
> optional requirements.
> On 11-06-01 10:39 AM, Sievers, Jan wrote:
> >> Heh. This was exactly my plan when I started to integrate p2 into
> >> tycho few years back. I actually had working prototype that took
> >> top-level features, calculated resolved dependency set and reported
> >> on loose IUs. There was also a way to provide additional resolution
> >> constrains to further lock down the resolution. I think this is the
> >> right approach, but as I mentioned earlier, I am not positive this
> >> is possible to implement in p2 3.6+.
> > Hmm. I am not sure myself but Tobias told me this is related to
> > slicer mode.
> > What I understood is that in planner mode you can get those
> > "dangling" requirements (required but not included, and thus possibly
> > with version ranges), whereas in slicer mode you only get the
> > (transitively) included bundles, and these always have perfect
> > version matches.
> > Maybe Tobias can comment?
> > Regards, Jan
> tycho-dev mailing list