| Re: [tycho-user] externalize version of bundle outside manifest |
Hi Fevre,
There are ways to achieve what you want, but I agree with previous commenters who believe it is a mistake. Why do you think that "it would be pertinent to ensure homogeneous versions across sub modules"?
In case your components have the same development and release cadence, it may be a better idea to merge them instead of dully updating all versions simultaneously.
In case what you really want is to run integration tests and deliver a consistent set of components, it may be better to achieve this by picking up specific component versions elsewhere. One place where they can be specified is in feature.xml, but it may be a bit cumbersome to update versions. Another place is a target definition file, in which case you can use JBoss Tools' target-platform-utils to update versions and create p2 repositories. A third place would be to manage it via binary artifact manager such as Nexus.
I cannot think of other uses cases, honestly. However, if you still want to factor out versions from manifest, feature and product files, you can do this. For example, one can use tycho-versions-plugin or version-tiger to set plugin versions, include unversioned dependencies in manifest files, and put dependencies with version numbers in pom.xml, but this would make it difficult to create a valid target platform to be able to code in Eclipse PDE. JBoss Tools' tycho-dependency-plugin may be able to help you here, but why create a problem in the first place?
I've seen this suggestion several times but so far nobody was able to explain me why moving versions out of manifest files was really necessary. In all those cases it was a wrong solution for some other problem.
Ok, thanks for this useful precision.
Nevertheless I was thinking (perhaps wrongly) that inside a project, it would be pertinent to ensure an homogeneity across sub modules.
Sometimes I have personally failure in the installation procedure in Eclipse due to osgi bundle version conflicts. For instance in Papyrus we use mainly a specific version and not a range in our MANIFEST.MF. The goal for me was to find a process to reduce this build/installation risk.
For instance, Tycho allows to use the mechanism of filtering on the target configuration [1]. I was not sure if it was usable for my problem.
Finaly, it seems to be pointless (and counter-productive).
[1]: https://wiki.eclipse.org/Tycho/Target_Platform#Filtering
De : tycho-user-bounces@xxxxxxxxxxx [mailto:tycho-user-bounces@eclipse.org] De la part de Jeff MAURY
Envoyé : jeudi 3 décembre 2015 11:18
À : Tycho user list <tycho-user@xxxxxxxxxxx>
Objet : Re: [tycho-user] externalize version of bundle outside manifest
+1 to Camille proposition
Jeff
On Thu, Dec 3, 2015 at 11:03 AM, LETAVERNIER Camille <Camille.LETAVERNIER@xxxxxx> wrote:
Hi,
This seems pointless (and counter-productive): the required version specifies the minimum version (Or version range) required by the current bundle. It is used to ensure compatibility at build & installation time.
P2 will then ensure that the installation is consistent (Or fail if the problem is unsatisfiable).
Automating this would only reduce the range of supported versions and the flexibility of custom installations.
For example, some bundles might require specific versions of UML (5.x) because they rely on its metamodel, while other bundles would work with any version of UML2 (e.g. the bundles that only provide helpers for general UML Concepts that haven’t changed since UML2 1.0.0)
Forcing a version range of “exactly 5.1.0” removes all the benefits of the “acceptable version range” for each bundle: someone who’d like to use only the “helpers bundle” (In practice, compatible with the entire UML2 range) wouldn’t be able to use it with UML2 4.1.0 because the range would be over-constrained by such a tool. And if he wants to install both the “helpers bundle” (With the [1.0.0, 6.0.0[ compatibility range) and the “metamodel-specific bundle” (With the [5.0.0, 6.0.0[ compatibility range), then P2 would be smart enough to determine that the only solution is using a UML2 5.x bundle.
So it’s probably not supported by Tycho, and it shouldn’t
In addition, Tycho is Manifest-first (Pom generated from the Manifest, not the other way round), so that would certainly be against the Tycho philosophy
Camille
De : tycho-user-bounces@xxxxxxxxxxx [mailto:tycho-user-bounces@xxxxxxxxxxx] De la part de LE FEVRE FRANCOIS
Envoyé : jeudi 3 décembre 2015 09:30
À : Tycho user list <tycho-user@xxxxxxxxxxx>
Objet : [PROVENANCE INTERNET] Re: [tycho-user] externalize version of bundle outside manifest
Jeff & Tycho user communauty,
Sorry to come back on this.
To make my question perhaps more clear:
I have one eclipse Tycho project with many eclipse-plugin submodules
Each of them has their own MANIFEST.MF
Sometimes they share the same Required Bundles.
I would like to make sure that all manifests have the same bundle version
For instance
I have sometimes:
Org.eclipse.uml2.uml;bundle-version=”5.0.0”
Org.eclipse.uml2.uml;bundle-version=”5.1.0”
With basic java maven projects, I could externalize the version number in the parent pom, ensuring I have the same version across all children modules.
Here I do not know how to do it?
Thanks in advance.
Francois
De : tycho-user-bounces@xxxxxxxxxxx [mailto:tycho-user-bounces@xxxxxxxxxxx] De la part de Jeff MAURY
Envoyé : lundi 23 novembre 2015 10:45
À : Tycho user list <tycho-user@xxxxxxxxxxx>
Objet : Re: [tycho-user] externalize version of bundle outside manifest
Hace a
On Mon, Nov 23, 2015 at 8:54 AM, LE FEVRE FRANCOIS <francois.le-fevre@xxxxxx> wrote:
Dear all,
I would like to know if it is possible to externalize a specific bundle version outside the manifest.
I have a multiple eclipse modules project managed by Tycho.
So I have Manifest.MF and pom.xml
I wanted to benefit of maven filtering feature in order to replace at build time the version of a specific bundle used at several places.
But it seems not to be possible since Tycho build phase is before maven verify phase.
Do you know how I can factorize my bundle version with a maven properties in the parent pom?
In order to be sure all eclipse plugins use the same version of the bundle?
Thanks
Francois
Francois LE FEVRE
Research Engineer
Commission for Atomic Energy and Alternative Energies (CEA)
Model-driven Engineering for Embedded Systems Laboratory (LISE)
Projet: Papyrus: https://www.eclipse.org/papyrus/
Commissariat à l’énergie atomique et aux énergies alternatives (CEA)
Paris-Saclay Campus - Nano-INNOV | Bât. 862-PC1087 | F-91191 Gif-sur-Yvette Cedex
T. +33 (0)1 69 08 49 86 | F. +33 (0)1 69 08 83 95 |
francois.le-fevre@xxxxxx | Blog: http://biocamp.blogspot.fr/
_______________________________________________
tycho-user mailing list
tycho-user@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/tycho-user
--
Jeff MAURY
"Legacy code" often differs from its suggested alternative by actually working and scaling.
- Bjarne Stroustrup
http://www.jeffmaury.com
http://riadiscuss.jeffmaury.com
http://www.twitter.com/jeffmaury
_______________________________________________
tycho-user mailing list
tycho-user@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/tycho-user
--
Jeff MAURY
"Legacy code" often differs from its suggested alternative by actually working and scaling.
- Bjarne Stroustrup
http://www.jeffmaury.com
http://riadiscuss.jeffmaury.com
http://www.twitter.com/jeffmaury
_______________________________________________
tycho-user mailing list
tycho-user@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/tycho-user
