On 22.07.2010, at 22:08, Tim Black wrote:
> 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.
>
> Or alternatively you can install the eclipse centrally and use a shared install. This may make sense if you *nix based and your IT infrastructure means that you have tools installed centrally on shared NFS filers:
>
http://help.eclipse.org/help32/topic/org.eclipse.platform.doc.isv/reference/misc/multi_user_installs.html
>
> Cheers,
> James
>
>
> _______________________________________________
> 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
