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