Community
Participate
Working Groups
Build Identifier: A feature.xml defines a plugin inclusion using version 0.0.0. The build is expected to replace the version with the latest available version of the related bundle. The current implementation uses the org.eclipse.equinox.internal.p2.director.Projector to determine a provisioning plan for installing the feature installation. This is done under the implicit assumption that the projector will always prefer the latest version of a dependency with unspecified version constraint. This is not the case. Other factors like install size might be take into account by the projector. The build should replace the required bundle versions with the latest available bundle version prior to calculation the provisioning plan. Reproducible: Didn't try Steps to Reproduce: A reproducible complex, internal example exists. Did not create a simple example to be attached.
Created attachment 199972 [details] Reproducible example
This problem probably also occurs in other places where "0.0.0" is used as a placeholder for including the latest version, like products and category.xmls.
Fixing this with the current target platform/dependency resolver setup is quite hard because it would need to be fixed in two places: near the dependency-only publishing and in the actual build. The restructuring proposed in bug 353889 would reduce this to one instance... (a perfect solution if the restructuring would be so much work).
The plugin version replacement is tested in these integration tests: DotQualifierMatchingTest ("1.0.0.qualifier") and ExpandReleaseVersionTest ("0.0.0")
Work in progress is posted here: [1] There are still a few open questions about the implementation: * Which versions shall match the declarations in the feature.xml? See discussion on tycho-dev [2]. I'd propose to drop the "1.0.0 matches [1.0.0, 1.0.1)" support for features, but this would be an incompatible change and should be discussed with the community. * Which attributes to check when matching IUs? Only the unit id (as done by the p2 publishers)? Or also the provided capabilities and/or properties (as done by the Tycho p2 resolver)? * How to handle projects using the local resolver? In the current state of the change [1], only projects with resolver=p2 can build features. Given the number of open questions, this bug won't make it into 0.21.0 [1] https://git.eclipse.org/r/#/c/29182/1 [2] https://dev.eclipse.org/mhonarc/lists/tycho-dev/msg01094.html
Hooray, more progress!! (In reply to comment #5) > There are still a few open questions about the implementation: > * Which versions shall match the declarations in the feature.xml? See discussion > on tycho-dev [2]. I'd propose to drop the "1.0.0 matches [1.0.0, 1.0.1)" support > for features, but this would be an incompatible change and should be discussed > with the community. I'd rather comply with the PDE UI behaviour. IMHO the less-known/less-used site.xml format doesn't justify the inconsistency in the feature.xml processing. > * Which attributes to check when matching IUs? Only the unit id (as done by the > p2 publishers)? Or also the provided capabilities and/or properties (as done by > the Tycho p2 resolver)? Actually, the publishers also check capabilities and attributes. So I did the same in the new implementation, and hence the new behaviour is consistent to the resolver. > * How to handle projects using the local resolver? In the current state of the > change [1], only projects with resolver=p2 can build features. Projects with local resolver now no longer replace the versions on references in the feature.xml. The local resolver has now been deprecated for years, so I didn't keep a second implementation for the local resolver. The current status is here: https://git.eclipse.org/r/#/c/29182/
Submitted: http://git.eclipse.org/c/tycho/org.eclipse.tycho.git/commit/?id=4873413ee243517d933e8aa595374623edbec865 Yay, so now we have the fourth oldest Tycho bug fixed. The fix is really not that exciting, but the changes in the internals (introduction of the target platform, preliminary vs. final metadata in the target platform, the local Maven repository as real p2 artifact repository, and the pluggable artifact providers with transparent caching) mean a lot! Good that this is done.
