[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [cdt-dev] Re: Re: questions about building and modifying CDT plugins
|
This question tends to pop up again and again :)
My understanding is:
-- The documented method to install plugins you are referring to may possibly have worked five years ago or so.
-- In the meantime it was updated to some new method or just broke. Most likely just nobody really cares about this usecase.
-- Nobody bothered to update or remove the documentation, leaving new users like you (and myself a year ago) stumbling.
The only working solution I have found is to checkout the sources, build and export the plugin into the running instance.
Best,
Tobias
Am 11.03.2010 um 00:39 schrieb Tim Black:
> 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?
> Try relaunching eclipse with the -clean argument
>
> 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.
>
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cdt-dev