Discussion:
[tycho-user] Enforcing package version constraints
Pascal Rapicault
2017-11-14 02:10:49 UTC
Permalink
How about properly crafting your target platform to include Guava 20
instead of Guava 15 so PDE generates the right input?
We're trying to use `Import-Package` in our bundles. PDE's quick-fixes for adding an import-package helpfully provides a `version` constraint where possible, but it uses the lowest version available in the target platform. So when developing against a TP for Eclipse Mars, where m2eclipse pulls in Guava 15, all com.google.common.* packages are added with version "15.0.0". Since we use Guava 20, we have to remember to change any such version constraints be "[20,21)". Such is life.
Except I'm old and frequently forget to change these package versions and so would like some way to catch these uses at build time. They aren't caught by the Maven dependency plugin's enforcer as Tycho/p2 resolves the dependencies and selects Guava 20 for the reactor.
Anybody know of any solutions? I suppose even a grep-for-pattern would work (e.g., `com.google.common.*;version="15.0.0"` would work for this particular case); I wonder if ant has something…
Brian.
_______________________________________________
tycho-user mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/tycho-user
Tom Bryan (tombry)
2017-11-13 23:14:32 UTC
Permalink
If you’re developing a plug-in that must work in multiple versions of Eclipse, and you require something like guava 20, which is not available in older versions of the Eclipse RCP, then do you must have the guava version 20 plug-in available for testing, right? In that case, can you just set up your target platforms so that they exclude the guava plug-in that comes from Eclipse Mars? Remove it from the bundle, or change the TP definition in Eclipse so that it’s not there.

Then you’d just need to do that across all of your supported target platforms and for all third-party dependencies that you need to control.

---Tom

On 11/13/17, 4:36 PM, "tycho-user-***@eclipse.org on behalf of Brian de Alwis" <tycho-user-***@eclipse.org on behalf of ***@gmail.com> wrote:

We're trying to use `Import-Package` in our bundles. PDE's quick-fixes for adding an import-package helpfully provides a `version` constraint where possible, but it uses the lowest version available in the target platform. So when developing against a TP for Eclipse Mars, where m2eclipse pulls in Guava 15, all com.google.common.* packages are added with version "15.0.0". Since we use Guava 20, we have to remember to change any such version constraints be "[20,21)". Such is life.

Except I'm old and frequently forget to change these package versions and so would like some way to catch these uses at build time. They aren't caught by the Maven dependency plugin's enforcer as Tycho/p2 resolves the dependencies and selects Guava 20 for the reactor.

Anybody know of any solutions? I suppose even a grep-for-pattern would work (e.g., `com.google.common.*;version="15.0.0"` would work for this particular case); I wonder if ant has something…

Brian.
_______________________________________________
tycho-user mailing list
tycho-***@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/tycho-user
Pascal Rapicault
2017-11-14 03:28:55 UTC
Permalink
You can exclude a plugin from Tycho's target platform using
https://wiki.eclipse.org/Tycho/Target_Platform#Filtering.
In PDE, I think you can go to the plug-ins mode and select the plugins
you want, and then add the other one.
Is there a way for the TP to exclude an artifact?
Our TP includes the version of m2eclipse that was contributed to the Mars release train, which requires com.google.guava [14.0.1,16.0.0). Although we could include the most recent release of m2e in our TP, I'm fairly sure that our users still using Mars will be using the m2e contributed on the release train. Maintaining a testing TP and a development TP doesn't sound like much fun, especially since we're maintaining a TP for each release train already.
Brian.
How about properly crafting your target platform to include Guava 20 instead of Guava 15 so PDE generates the right input?
We're trying to use `Import-Package` in our bundles. PDE's quick-fixes for adding an import-package helpfully provides a `version` constraint where possible, but it uses the lowest version available in the target platform. So when developing against a TP for Eclipse Mars, where m2eclipse pulls in Guava 15, all com.google.common.* packages are added with version "15.0.0". Since we use Guava 20, we have to remember to change any such version constraints be "[20,21)". Such is life.
Except I'm old and frequently forget to change these package versions and so would like some way to catch these uses at build time. They aren't caught by the Maven dependency plugin's enforcer as Tycho/p2 resolves the dependencies and selects Guava 20 for the reactor.
Anybody know of any solutions? I suppose even a grep-for-pattern would work (e.g., `com.google.common.*;version="15.0.0"` would work for this particular case); I wonder if ant has something…
Brian.
_______________________________________________
tycho-user mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/tycho-user
_______________________________________________
tycho-user mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/tycho-user
_______________________________________________
tycho-user mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/tycho-user
Brian de Alwis
2017-11-21 04:05:49 UTC
Permalink
Thanks Pascal — I wasn't aware of Tycho's TP filtering capabilities. It doesn't help in this particular case as we still have to pull in m2e which depends on Guava 15.

We have some unit bundle-shape validation tests that we add to each of our test fragments to do validation on things like missing files from build.properties, missing i18n keys, and basic plugin.xml validation. We added a rule to check for undesirable package version strings.

Brian,
You can exclude a plugin from Tycho's target platform using https://wiki.eclipse.org/Tycho/Target_Platform#Filtering.
In PDE, I think you can go to the plug-ins mode and select the plugins you want, and then add the other one.
Is there a way for the TP to exclude an artifact?
Our TP includes the version of m2eclipse that was contributed to the Mars release train, which requires com.google.guava [14.0.1,16.0.0). Although we could include the most recent release of m2e in our TP, I'm fairly sure that our users still using Mars will be using the m2e contributed on the release train. Maintaining a testing TP and a development TP doesn't sound like much fun, especially since we're maintaining a TP for each release train already.
Brian.
How about properly crafting your target platform to include Guava 20 instead of Guava 15 so PDE generates the right input?
We're trying to use `Import-Package` in our bundles. PDE's quick-fixes for adding an import-package helpfully provides a `version` constraint where possible, but it uses the lowest version available in the target platform. So when developing against a TP for Eclipse Mars, where m2eclipse pulls in Guava 15, all com.google.common.* packages are added with version "15.0.0". Since we use Guava 20, we have to remember to change any such version constraints be "[20,21)". Such is life.
Except I'm old and frequently forget to change these package versions and so would like some way to catch these uses at build time. They aren't caught by the Maven dependency plugin's enforcer as Tycho/p2 resolves the dependencies and selects Guava 20 for the reactor.
Anybody know of any solutions? I suppose even a grep-for-pattern would work (e.g., `com.google.common.*;version="15.0.0"` would work for this particular case); I wonder if ant has something…
Brian.
_______________________________________________
tycho-user mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/tycho-user
_______________________________________________
tycho-user mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/tycho-user
_______________________________________________
tycho-user mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/tycho-user
_______________________________________________
tycho-user mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/tycho-user
Loading...