[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cdt-dev] best practices for managing a custom eclipse/CDT build in a C++ development organization
|
Thanks, Everyone, for your suggestions. We may someday consider setting up a single shared/multi-user eclipse installation, but for my current needs, making copies of an eclipse installation folder is probably the simplest way to achieve what I want to do. My "users" don't have to know about plugins, etc, they just copy the eclipse install dir just like they do with public releases. Now I just have to get my exported plugins to work (like they did when I did Run As -> Eclipse Application)...
Thanks for mentioning the dropins/ folder. Didn't know that existed. I tried dropping my patched ,exported .jars into dropins/ but the result is still a failure, i.e. (a) Plug-ins tab of Eclipse Installation Details still shows the old version for those plugins, and (b) the new patched behavior is not present (like it was when I did "Run As" "Eclipse Application" on org.eclipse.cdt.ui)
I've been through this before and still haven't figured out how to "deploy plugins". Can anyone see what I've done wrong?
0. Starting with the standard Helios/CDT7.0 release (for C/C++ developers), I installed Eclipse SDK using Help->Install New Software. Restarted Eclipse and switch to Plugin Dev Perspective.
1. Got CDT HEAD using project set file import.
2. Build all CDT plugins in workspace. (There are errors but only in org.eclipse.cdt.tests.dsf)
3. Got and applied latest CDT patch (for viewing STL containers) at
https://bugs.eclipse.org/bugs/show_bug.cgi?id=302121.
4. Build all CDT plugins in workspace. There are no more errors than before. Good.
5. Right click org.eclipse.cdt.ui and Run As.. Eclipse Application. New plugin behavior is present (pretty print view of STL containers). About Eclipse - Eclipse Installation Details - Plug-ins just shows "qualifier" for the qualifier for versions of CDT plugins. Close the "Run As" Eclipse instance.
6. Back in the Plugin Package Explorer, there are only 2 CDT plugins with ">" appended to their name indicating they have been modified. These are org.eclipse.cdt.dsf.gdb and org.eclipse.cdt.dsf.gdb.ui. Select both, and Export... Deployable plug-ins and fragments. Specify directory but change no other defaults. (qualifier defaults to date/time)
7. Close Eclipse. There are now no eclipse instances running. Make copies of eclipse/ install folder called eclipse_test1/ and eclipse_test2/.
8. At this point I tried a few approaches:
a. Copy the 2 patched .jar files into eclipse_test1/plugins/. There are now 2 .jars for each of the patched plugins, with different versions (the patch must have modified this) and qualifiers.
The result running this eclipse is that Eclipse Installation Details still shows the old versions of the plugins, but I get some partial expected behavior (pretty print works but opening up a vector doesn't work)
b. Delete the older versions of patched .jars, leaving just the ones I just built.
The result running this eclipse is that eclipse doesn't even load my patched plugins and the dsf gdb debugging behavior and ui is wrong. Probably a version dependency problem..
c. Now using a fresh eclipse install. Copy the 2 patched .jar files into eclipse_test2/dropins/. There are still the original unpatched .jars in plugins/.
Same result as a. The result running this eclipse is that Eclipse Installation
Details still shows the old versions of the plugins, but I get some
partial expected behavior (pretty print works but opening up a vector
doesn't work)
Thanks,
T
On Thu, Jul 22, 2010 at 2:28 AM, James Blackburn
<jamesblackburn@xxxxxxxxx> wrote:
On 22 July 2010 10:21, Beth Tibbitts
<tibbitts@xxxxxxxxxx> wrote:
>It looked to me like the thing to do is "Export" "Eclipse Product".
No, that is for building an RCP product.
You want to export deployable plug-ins and fragments.
You could build a set of the plug-ins that you have changed, and your users could apply those to the downloaded CDT installation.
You just want the version numbers to be greater than the default CDT's so they are recognized.
On the options tab of the export dialog, the "qualifier replacement" can use today's date and thus it's "greater than" the date that the base CDT was built.
I think what you build this way, your users could copy into the eclipse/dropins folder to install.
Alternatively you could build an update site.
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
