Re: [tycho-dev] what is the "target platform"?

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

Igor Fedorenko wrote:
> I would define target platform (or TP for short) as "a set of artifacts,
> other reactor projects and associated p2 metadata which a project will
> be built against". This definition does not imply any particular way to
> define the set, nor it makes any assumptions about the set itself.

This is too fuzzy for a definition. It could mean:
a) TP = artifacts used for compilation. This definition does not match the PDE definition, because the PDE TP is the set of artifacts that _may_ be used for compilation, regardless whether they are actually used or not.
b) TP = artifacts that can be used by the build. In case of repository with layout p2, anything from that p2 repository can be used by the build, so the TP contains the entire content of the p2 repository. In my opinion, this is correct - but this is not what you propose.

You propose a mixture of a and b, i.e. as something that _may_ depend on the project dependencies. Why would you choose such a complicated, messy definition? Obviously, the compile class path is a function of the project dependencies, but if the TP is also a function of the project dependencies, the TP definition becomes arbitrary and is only defined through the implementation. This is impossible to understand for someone who hasn't written the code.

And btw. try to document your definition - IMHO documentation which just repeats the implementation is crap. Tycho is too complex to be understandable without abstraction. Therefore: TP should be a function of the configuration, and independent of the project dependencies.

> How TP is used during the build is indeed very specific to a project
> type. So, for example, for eclipse-plugin projects TP will be used to
> construct compile classpath and for eclipse-product projects TP will by
> p2 director to calculate RCP contents and source required artifacts.

And eclipse-feature uses it to replace 0.0.0 plug-in inclusions. And then we get really deep into the definition swamp: the resolver uses the "project dependencies" to compute the "target platform", followed by the packaging plugin that uses the "target platform" to compute the "project dependencies".

Sorry, but this proves that your definition is broken.
 
> At implementation level, target platform is the output of
> TargetPlatformResolver.resolvePlatform method. In the case of .target
> file, TP contents should not depend on the project itself, so we do have
> a problem in the current implementation, i.e. in your example step #3 is
> not needed. I think the best way to address this is to refactor
> TargetDefinitionResolver into a ResolutionStrategy. This should also fix
> the problem with .qualifier expansion in feature.xml and other places.
> Unless there are objections, I'll try to do this tomorrow or day after.

I object - the discussion has not yet come to an agreement.

> Btw, Equinox resolver does not actually need the list of local
> artifacts. It only need manifests of all osgi bundles from the TP. I
> believe bundle manifests are available in P2 IU already, so in theory we
> can implement lazy target platform, which will not require eager
> download of all artifacts.

This is not API of p2 - and it has changed: https://bugs.eclipse.org/bugs/show_bug.cgi?id=329386

Regards
Tobias

> 
> --
> Regards,
> Igor
> 
> On 11-11-16 3:53 AM, Oberlies, Tobias wrote:
> > In the discussion about bug 363331 [1], I realized that we have a
> different understanding about the term "target platform", which makes it
> really hard to discuss about the actual problem.
> >
> > This is how I understand the "target platform" at the example what Tycho
> does for an eclipse-plugin project:
> >
> > 1. If a target file is specified, the TargetDefinitionResolver resolves
> the target file
> > 2. ResolutionContextImpl.gatherAvailableInstallableUnits computes the
> "target platform"
> > 3. P2ResolverImpl.resolveProject resolves project dependencies. The
> result doesn't have a good name - the best I can think of is "resolved
> project dependencies"
> > 4. The equinox resolver (don't know the class exactly) takes the
> resolved project dependencies and computes the class path from this.
> >
> > IMHO it is very important to distinguish between the "target platform"
> and dependency resolution, because all packaging types need a "target
> platform", but not all of them need dependency resolution:
> > - eclipse-plugin needs dependency resolution because the Equinox
> resolver (step 4) needs a list of local artifacts (the "resolved project
> dependencies" - in contrast to the target platform which is only a list of
> IUs)
> > - eclipse-feature does not need dependency resolution. The root cause
> for bug 352081 [2] is that the 0.0.0 replacement is done by taking the
> latest version from "resolved project dependencies" instead of from the
> "target platform". Dependency resolution could be done as consistency
> check (e.g. to prevent the build of a feature which cannot be installed
> later), but not all tycho users want this (see bug 353399 [3]).
> > - eclipse-product does not need dependency resolution - the director can
> directly operate on the "target platform"
> > - eclipse-repository cannot use the dependency resolution result, if we
> want to allow more flexible aggregation rules (e.g. multiple versions of
> bundles)
> >
> > Does this make sense to you?
> >
> > Regards
> > Tobias
> >
> >
> > [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=363331 : specify
> additional target platform requirements in pom.xml
> > [2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=352081 : Handling of
> version 0.0.0 in feature plugin inclusions
> > [3] https://bugs.eclipse.org/bugs/show_bug.cgi?id=353399 : Feature
> require import show warn, not fail.
> > _______________________________________________
> > 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