| Re: [cdt-dev] Patching a CDT plugin |
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 From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Doug Schaefer 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. Doug. Sent from my BlackBerry Z30
I don't think modifying the manifest is necessary. -sergey 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 From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Sergey Prigogin 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. -sergey On Thu, Mar 6, 2014 at 7:24 PM, Guy Bonneau <guy.bonneau@xxxxxxxxxxxx> wrote: I am developing a commercial plugin that use Eclipse’s CDT and need to patch 3 CDT plugins to fixe some issues I already reported on Bugzilla without which the usage of the plugin will fail. I have reviewed the thread of Joseph Henry about the distribution of custom patches: https://dev.eclipse.org/mhonarc/lists/cdt-dev/msg26205.html . I have also read some info posted on Eclipse Wiki about how to use fragment to patch a plugin: https://wiki.eclipse.org/RAP/Patch_Fragments and https://wiki.eclipse.org/Steps_to_use_Fragments_to_patch_a_plug-in as I am struggling to choose a strategy for this. Now regarding the strategy of using a fragment to patch a plugin. It is not clear to me if the manifest of the host plugin must be modified with the attribute Eclipse-ExtensibleAPI: true. If the Host Manifest need to be modified obviously I cannot ask an end user to do this. This would be an insane way to patch a plugin. Can anyone shade some light regarding this? Thanks Guy
|