Thanks Marc I’ll have a look at this. However this create a dilemma. Since new functionalities are added every release to some of the plugins I need to patch I’ll have to provide a different plugin patch for each CDT release. And this create a versioning and support headache. I need to review this but I believe the few classes I want to change are stable since a few years. Thus patching only the specific classes would remove the CDT versioning issue and would keep the CDT specific feature of each release. Unless of course I introduce an issue with the code change I make to the patch classes. This is why I believe the fragment patch seems to be my best bet yet even though it is not officially supported. I guess I’ll have to try it to know better. Guy From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Marc Khouzam Sent: Friday, March 07, 2014 3: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
|