Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [tycho-user] is it possible to override version requirements?

And the JDT patching is documented here: 
Also Groovy Eclipse provides feature patches for JDT, but they build it in a different way, by using a deprecated maven archetype (iirc, eclipse-update-site).

On Mon, Feb 1, 2021 at 6:39 AM Ed Merks <ed.merks@xxxxxxxxx> wrote:
I got the impression that the only hard version requirement came from a
feature, not a plugin, and that's generally because the feature includes
the plugin with a 0.0.0 version which is replaced with an exact version
at build time.


This is the "normal" way one includes bundles in features...

But the bundles look like this, for example, so do use version ranges:

Require-Bundle: org.eclipse.equinox.common;bundle-version="[3.0.0,4.0.0)",
Import-Package: org.apache.http;version="[4.4.0,5.0.0)",

In terms of examples of patch features JDT always ships patch features
for the version of JDT that supports the soon-to-be-released version of

On 01.02.2021 06:04, Christoph Läubrich wrote:
> If your interested in help improving support for patch-features feel
> free to contribute :-)
> You will still have the problem that the plugin itself has a hard
> version requirement so you need to patch this as well (and probably
> others that require this and so on). Patch features are mainly useful
> if you like to provide an Update-Site and let users install the patch,
> but I have never used them.
> If you simply need to replace temporary a hard dependency like this it
> seems the best to to build a jar with the exact version of the
> replacement and simply swap out the jar in the plugin folder.
> Am 31.01.21 um 22:12 schrieb Homer, Tony:
>> Thanks Rolf!  I didn’t know about this possibility and it seems like
>> it matches my goals.
>> Reading the comments, 378794 is blocked by 372780, but fortunately,
>> Christoph and Mickael are both involved
>> <>
>> 😉
>> The bug describes a workaround for the problem which I understand,
>> but I’m not sure how to integrate a feature patch into my build for
>> producing an Eclipse product.
>> I suppose after I make the feature patch and deploy it to a combined
>> P2 repo (as described in
>> <>), I would
>> add it to the product file and the target definition. Would
>> dependency resolution respect the dependency version in my feature
>> patch?
>> I’ll have to experiment with it, I suppose, but if anyone has used
>> feature patches in an eclipse product that is being built for
>> distribution, please let me know!
>> Thanks again, Rolf!
>> Tony Homer
>> *From: *tycho-user <tycho-user-bounces@xxxxxxxxxxx> on behalf of Rolf
>> Theunissen <rolf.theunissen@xxxxxxxxx>
>> *Reply-To: *Tycho user list <tycho-user@xxxxxxxxxxx>
>> *Date: *Sunday, January 31, 2021 at 6:19 AM
>> *To: *Tycho user list <tycho-user@xxxxxxxxxxx>
>> *Subject: *Re: [tycho-user] is it possible to override version
>> requirements?
>> Hi,
>> Isn't this where Feature patches are intended for? "A Feature Patch
>> Project can contain plug-ins which replace existing plug-ins.", see
>> <> or
>> <>
>> Though feature patches are not well supported by Tycho, see
>> <>
>> Best Regards,
>> Rolf
>> Op zo 31 jan. 2021 om 00:06 schreef Mickael Istria
>> <mistria@xxxxxxxxxx <mailto:mistria@xxxxxxxxxx>>:
>>     Hi,
>>     On Sat, Jan 30, 2021 at 11:28 PM Homer, Tony <tony.homer@xxxxxxxxx
>>     <mailto:tony.homer@xxxxxxxxx>> wrote:
>>         However, today I wondered, is it somehow to possible to override
>>         the dependency requirements?
>>     That's a bit too hacky IMO, but maybe a combination of
>> <>
>>     and
>> <> can work.
>>     But in this case, the issue is really that the feature requires the
>>     "regular" version and Tycho won't change the feature. So even if you
>>     manage to hack the dependency resolution at build time, this
>>     resolution error you see now in Tycho would still be likely to
>>     happen later for people trying to install...
>>     So in this case, you'll need to tweak the
>>     org.eclipse.ecf.filetransfer.httpclient45.feature (or most likely
>>     build a fork of it) so it doesn't require this specific version of
>>     the bundle, but can use any version. This is usually possible by
>>     replacing a direct <plugin> element (which mandates specific
>>     version) by a `<requires><import
>> plugin="org.apache.httpcomponents.httpclient"/></requires>` which
>>     results in more open version range and would pick anyone that
>> matches.
>>     If you add the fixed bundle build and the "relaxed" feature build to
>>     your build, they should be used by the product instead of the ones
>>     from upstream, and it should then work; unless there is something
>>     else that requires the specific version of feature or bundle.
>>     HTH
>>     _______________________________________________
>>     tycho-user mailing list
>>     tycho-user@xxxxxxxxxxx <mailto:tycho-user@xxxxxxxxxxx>
>>     To unsubscribe from this list, visit
>>     <>
>> _______________________________________________
>> tycho-user mailing list
>> tycho-user@xxxxxxxxxxx
>> To unsubscribe from this list, visit
> _______________________________________________
> tycho-user mailing list
> tycho-user@xxxxxxxxxxx
> To unsubscribe from this list, visit
tycho-user mailing list
To unsubscribe from this list, visit

Linux. The choice of a GNU generation.

Back to the top