Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] Patching a CDT plugin

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/

 

 

From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Guy Bonneau
Sent: Friday, March 07, 2014 7:59 AM
To: 'CDT General developers list.'
Subject: 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
Sent: Friday, March 07, 2014 2:34 AM
To: cdt-dev@xxxxxxxxxxx; CDT General developers list.
Subject: Re: [cdt-dev] Patching a CDT plugin

 

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

From: Sergey Prigogin

Sent: Friday, March 7, 2014 1:51 AM

To: CDT General developers list.

Reply To: CDT General developers list.

Subject: Re: [cdt-dev] Patching a CDT plugin

 

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
Sent: Thursday, March 06, 2014 10:39 PM
To: CDT General developers list.
Subject: Re: [cdt-dev] Patching a CDT plugin

 

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


_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev

 


_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev

 


Back to the top