We use the feature patch mechanism to patch CDT. Just create a new feature and list whatever plugins you’re patching in it. Then add something like this to
it:
<requires>
<import
feature="org.eclipse.cdt.platform"
version="8.1.2.201302132326"
patch="true"/>
</requires>
setting the version number accordingly for your situation.
I hope that helps.
Thanks,
Warren
From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx]
On Behalf Of Marc Khouzam
Sent: Friday, March 07, 2014 2:46 PM
To: 'CDT General developers list.'
Subject: Re: [cdt-dev] Patching a CDT plugin
I haven’t looked into this in a while, but a Feature Patch may be of interest.
I believe it will allow you to install a new version of the feature that is giving you trouble, replacing only the plugins you have changed.
I found this blog but there are maybe better ones:
http://eclipsesource.com/blogs/2012/07/30/patching-your-own-eclipse-ide/
Thanks Doug.
I am not sure I have understood what both Sergey and you are trying to tell me. You seems to say there is another way than using fragment. Unfortunately I don’t
have much know how of Maven. That’s not my cup of tea but I am open to dig in it. Could you please elaborate? The implementation of the toolchain includes 2 plugins and 2 fragments. I expected to fix the issues of CDT by including in the toolchain plugin
a fragment for every plugin of the CDT that needed to be patched. Thus I would expect an end user that already installed CDT to install the toolchain plugin that contains the fragments to patch the CDT issues. Is there a better/cleaner way to do this ?
Guy
We do the same thing as Sergey and build the platform and CDT bits we need. That's the beauty of Maven.
Of course we contribute back any changes we make for the next release so we don't have to keep doing that.
Sent from my BlackBerry Z30
I don't think modifying the manifest is necessary.
On Thu, Mar 6, 2014 at 8:15 PM, Guy Bonneau <guy.bonneau@xxxxxxxxxxxx> wrote:
Thanks Sergey,
But rebuilding the whole CDT to provide a fix to a few classes seems to be overkill to provide a
new CDT toolchain. Even if I could do it then requesting an end user to reinstall the whole CDT would create an headache to the tech support.
I understand the issue of versioning as well. But the classes I need to modify are stable since a
few years and I don’t expect any changes in the short term. Thus I believe using the fragment strategy seems at first glance to be my best trade-off. This is why I am asking if the use of a fragment patch can be done without having to modify the manifest
of a host CDT plugin that is already installed within the Eclipse Platform of an end user? If this is not possible then I understand why you suggested to build the whole SDK. That would make sense.
Thanks
Guy
Fragments make version upgrades very hard. We used to use fragments for platform patches and abandoned this approach in favor of building the whole Eclipse SDK ourselves.
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
This message (including any attachments) is intended only for the use of the individual or entity to which it is addressed and may contain information that is non-public, proprietary, privileged, confidential, and exempt from disclosure under applicable law
or may constitute as attorney work product. If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this communication in error,
notify us immediately by telephone and destroy this message if a facsimile or (ii) delete this message immediately if this is an electronic communication. Thank you.
|