[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [tycho-dev] what is the "target platform"?
|
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.
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.
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.
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.
--
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
