Just copying a plugin with a new version won't work. The eclipse
plattform keeps track of the jars to use. AFAIK, you have to create a
new deployable feature version and update eclipse with the new one. To
much work for me -> I prefer #1 ;)
I don't understand this. The documentation says to export the plug-in from your SDK project and, using the Directory Destination method, this puts the .jar
directly into the target installation's plugins dir. I have verified that after the export process, there is a new .jar file sitting there with new mod date. I can do a "jar tf" on this file and see it seems to include boatloads of classes from org/eclipse/cdt/make/. Does the export
process do more than copy the .jar into the right place? Why wouldn't
this work?
I added -clean to my command line args for the target eclipse executable and still it doesn't seem to load the right plug-in. By "right" plug-in, I mean the org.eclipse.cdt.make.core.jar that I just generated using my eclipse SDK and making a slight modification. The "slight modifications" I have tried are:
0. no change except when exporting the plug-in, change the plug-in version qualifier which I thought I could
verifiy in the target installation via About Eclipse - Installation
Details - Plug-ins. Didn't work. Tried the same thing with manually incrementing the x in 6.0.0.x - it generate a correctly-named .jar (reflecting the new version #) but as I mentioned on an earlier post it wouldn't load in the target CDT installation.
1. change some of the strings in the MakeMessages.properties file in org.eclipse.cdt.make.internal.
core
- assuming it would change the string shown during a build operation
like changing "Updating project..." to "This is my test string..." and
then I could verify that in the target CDT installation. Didn't work.
2. commenting out the unconditional cal to refreshProject() after the build command completes. This didn't work either.
