[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [tycho-user] is it possible to override version requirements?
|
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.
<plugin
id="org.eclipse.ecf.filetransfer"
download-size="0"
install-size="0"
version="0.0.0"
unpack="false"/>
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)",
org.eclipse.ecf.provider.filetransfer;bundle-version="[3.2.200,4.0.0)",
org.eclipse.ecf;bundle-version="[3.4.0,4.0.0)",
org.eclipse.ecf.filetransfer;bundle-version="[5.0.0,6.0.0)"
Import-Package: org.apache.http;version="[4.4.0,5.0.0)",
org.apache.http.auth;version="[4.5.0,5.0.0)",
org.apache.http.client;version="[4.5.0,5.0.0)",
org.apache.http.client.config;version="[4.5.0,5.0.0)",
org.apache.http.client.methods;version="[4.5.0,5.0.0)",
org.apache.http.client.protocol;version="[4.5.0,5.0.0)",
org.apache.http.client.utils;version="[4.5.0,5.0.0)",
org.apache.http.config;version="[4.4.0,5.0.0)",
org.apache.http.conn.socket;version="[4.5.0,5.0.0)",
org.apache.http.conn.ssl;version="[4.5.0,5.0.0)",
org.apache.http.conn.util;version="[4.5.0,5.0.0)",
org.apache.http.impl.auth;version="[4.5.0,5.0.0)",
org.apache.http.impl.client;version="[4.5.0,5.0.0)",
org.apache.http.message;version="[4.4.0,5.0.0)",
org.apache.http.protocol;version="[4.4.0,5.0.0)",
org.apache.http.util;version="[4.4.0,5.0.0)",
org.eclipse.core.runtime.jobs,
org.eclipse.osgi.service.debug;version="[1.2.0,2.0.0)",
org.eclipse.osgi.util;version="[1.0.0,2.0.0)",
org.osgi.framework;version="[1.2.0,2.0.0)",
org.osgi.service.log;version="[1.2.0,2.0.0)",
org.osgi.util.tracker;version="[1.2.0,2.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
Java.
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
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=372780
>> <https://bugs.eclipse.org/bugs/show_bug.cgi?id=372780>
>>
>> 😉
>>
>> 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
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=378794#c14
>> <https://bugs.eclipse.org/bugs/show_bug.cgi?id=378794#c14>), 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
>> https://www.vogella.com/tutorials/EclipsePatching/article.html
>> <https://www.vogella.com/tutorials/EclipsePatching/article.html> or
>> https://eclipsesource.com/blogs/2012/07/30/patching-your-own-eclipse-ide/
>> <https://eclipsesource.com/blogs/2012/07/30/patching-your-own-eclipse-ide/>
>>
>>
>> Though feature patches are not well supported by Tycho, see
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=378794
>> <https://bugs.eclipse.org/bugs/show_bug.cgi?id=378794>
>>
>> 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
>> https://wiki.eclipse.org/Tycho/Target_Platform#Extra_requirements
>> <https://wiki.eclipse.org/Tycho/Target_Platform#Extra_requirements>
>> and https://wiki.eclipse.org/Tycho/Target_Platform#Filtering
>> <https://wiki.eclipse.org/Tycho/Target_Platform#Filtering> 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
>> https://www.eclipse.org/mailman/listinfo/tycho-user
>> <https://www.eclipse.org/mailman/listinfo/tycho-user>
>>
>>
>> _______________________________________________
>> tycho-user mailing list
>> tycho-user@xxxxxxxxxxx
>> To unsubscribe from this list, visit
>> https://www.eclipse.org/mailman/listinfo/tycho-user
>>
> _______________________________________________
> tycho-user mailing list
> tycho-user@xxxxxxxxxxx
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/tycho-user
_______________________________________________
tycho-user mailing list
tycho-user@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/tycho-user
--
Linux. The choice of a GNU generation.
