Re: [cdt-dev] Re: questions about building and modifying CDT plugins

[Tim Black <timblaktu@xxxxxxxxx>]

I had another go at locally fixing Eclipse Bug 133881. The goal is to prevent the project refresh that automatically happens at the end of each make. This time I reduced the set of changes required to one:

comment out lines 227-228 in MakeBuilder.java (version 6.0.0.201002161416 of org.eclipse.cdt.make.core):
These are the lines that print out "Updating project..." and then call refreshProject(). 

I thought this time was going to be a slam dunk but It didn't fix the problem. I exported the plug-in to my target CDT installation (also eclipse 3.5.2, also CDT 6.0.0) and it still refreshes after each make. Does anyone have any insight or guess as to why this didn't work? 

Thanks,
Tim

On Tue, Mar 9, 2010 at 12:37 PM, Tim Black <timblaktu@xxxxxxxxx> wrote:

Several people have suggested that I "check out the 6.01 or 6.02 branch" of CDT. Is the proper way to do this to get :pserver:anonymous@xxxxxxxxxxxxxxx:/cvsroot/tools/Versions/cdt-platform/cdt-platform CDT_6_0_2 ? This is the only place I found anything named 6.0.1 or 6.0.2. The only thing close I could find was in Branches - "cdt_6_0" - "cdt-platform cdt_6_0". What's the difference between this and Versions - cdt-platform - cdt-platform CDT_6_0_0?

When I checkout cdt-platform CDT_6_0_2 it pulls in 6 categorized projects all named org.eclipse.cdt-* that seem to encapsulate all the CDT plugins. But if I make a trivial change (like add a comment) to a source file within org.eclipse.cdt.make.core, and File - Export - Deployable plug-ins and fragments, nothing is listed in the "Available Plug-ins and Fragments" like it was when I had only org.eclipse.cdt.make.core as a source project imported into my workspace. Same behavior if I do File - Export - Deployable Features. What am I doing wrong?

Thanks,
Tim

On Tue, Mar 9, 2010 at 10:35 AM, Tim Black <timblaktu@xxxxxxxxx> wrote:

OK thanks. For now, since I'm just wanting to patch a single plug-in, I think I'll stick to the CVS-less method of importing the source project, building, and exporting the .jar to a target CDT installation. Before even attempting to apply the patch, I have done some experiments to try and learn about the eclipse plug-in model. These experiments have led to more questions:

0. If I replace the original org.eclipse.cdt.make.core_6.0.0.201002161416.jar with one built/exported from the source project, I can run the target eclipse CDT installation with no errors. (No plugin-loading errors in the Error Log View) This is expected as I should have made no changes.
1. If I bump the build# (the x in 6.0.0.x) in the plugin.xml for org.eclipse.cdt.make.core, and build/export it into the target CDT installation so that there are now 2 org.eclipse.cdt.make.core* in plugins/, I get no plugin-loading errors, but when I look at About Eclipse - Installation Details - Plug-ins - I see that the old org.eclipse.cdt.make.core was loaded, not the new one. From this, I infer that for a given plug-in name, Eclipse will dynamically load the first plug-in it finds with that name (alphabetically?) and not reload it when it finds other identically named ones. Is this correct?
2. If I delete all org.eclipse.cdt.make.core plug-ins and then export the org.eclipse.cdt.make.core with the bumped version number so that it is the only org.eclipse.cdt.make.core* in plugins/, I see a plug-in error for org.eclipse.cdt.core in the Error Log when I run the target eclipse CDT installation: "Error: required build system is not installed" When I look in About Eclipse at the list of loaded plug-ins, I do not see org.eclipse.cdt.make.core in there. Presumably, there is something wrong with the plug-in that I just built and exported, even though the only change I made to it was to bump the version build# from 6.0.0.201002161416 to 6.0.0.201002161417. Any idea what I might have done wrong?

I did all of this because I want to make sure my plug-in development environment is installed and working properly. I expected to be able to make a trivial but distinguishable change to org.eclipse.cdt.make.core, rebuild it by itself, export to a properly-versioned 6.0.x CDT installation, and test it with no errors.

org.eclipse.cdt.make.core has dependencies on other org.eclipse.core.* and org.eclipse.cdt.* plug-ins, but my understanding is that these are runtime dependencies. There is no reason why I can't build org.eclipse.cdt.make.core into a .jar by itself. And the fact that I get no errors when building org.eclipse.cdt.make.core by itself (without similarly importing as source projects and building all the other dependencies) tells me that this is the case. Let me know if this is an invalid assertion.

Once I've resolved the above questions and issues about building/deploying a plugin, I can move on to actually applying the patch. In the meantime, I am going to retry the CVS method (using the correct CDT branch for my sdk and target Eclipse installs) and see if I get better results.

Thanks,
Tim

On Tue, Mar 9, 2010 at 1:10 AM, Kaestel-Baumgartner Harald (DCC/EDF2) <Harald.Kaestel-Baumgartner@xxxxxxxxxxxxxxx> wrote:

> I will try this, but I wanted to ask: since I already have
> CDT plugged into
> my Eclipse Classic install, is it possible (or dangerous?) to
> just use this
> install to test the modified CDT plugin? Would it be the same
> mechanism -
> i.e. can I just export, shut down eclipse, copy the exported
> .jar into the
> same eclipse's plugins/, then restart it and test? Is that
> dangerous? Is
> there some PDE best-practices way that's better?

First, I would not call this way a best-practice since you've to be aware what you are doing. Especially when you don't change the version and replace the existing jar with the modified one. It's just a short cut to make changes. It's not really a common way to make changes and a I could imagine that a lot of people out there get a headache after reading that ;) But my experience is, creating a runtime patch with a new plugin version is not as easy.

I think a best-practice would be to build a new deployable CDT version.

AFAIK (I'm only an advanced user of eclipse/CDT): Yes, you could replace the jar of your classic installation. Alternitive, it should be possible to launch eclipse out of eclipse to test your changes.

--Harald

>
> Thanks,
> Tim
>
> On Fri, Mar 5, 2010 at 12:14 AM, Kaestel-Baumgartner Harald
> (DCC/EDF2) <
> Harald.Kaestel-Baumgartner@xxxxxxxxxxxxxxx> wrote:
>
> > >
> ----------------------------------------------------------------------
> > >
> > > Message: 1
> > > Date: Thu, 4 Mar 2010 16:57:19 -0800
> > > From: Tim Black <timblaktu@xxxxxxxxx>
> > > Subject: [cdt-dev] questions about building and modifying
> CDT plugins
> > > To: cdt-dev@xxxxxxxxxxx
> > > Message-ID:
> > >
> <f3cdbfbe1003041657p4931add6h81db28803de5a7fb@xxxxxxxxxxxxxx>
> > > Content-Type: text/plain; charset="iso-8859-1"
> > >
> > ...
> > > I did a fresh install of the current release (3.5.2r35) of
> > > the RCP/Plug-in
> > > Developers distribution of Eclipse, and then followed the
> > > instructions at
> > > http://wiki.eclipse.org/Getting_started_with_CDT_development.
> > > I checked out
> > > the listed plugins from HEAD->org.eclipse.cdt->all. Upon
> building all
> > > projects, several build errors and warnings accumulated. Many
> > > of the errors
> > > were "x cannot be resolved to a type" or "import y cannot be
> > > resolved".
> > ...
> >
> > FYI, how to without CVS access:
> > When I have to patch my own system I plug in CDT in my PDE
> installation and
> > then run import_as->Source_project via the Plug-ins view.
> Then I change the
> > sources of my plug-in, export it as plug-in and finally I
> manually replace
> > the jar in my CDT installation with the patched one.
> >
> > --harald
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev