[
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
|
> 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)
You should not change the plugins directory. You should
just use the dropins directory instead.
> > 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..
Same comment.
> > 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)
I thought that would work.
Try putting those new plugins in
dropins/eclipse/plugins
Note also that you cannot re-use version numbers, even
the version is different than the original plugin.
So, if things don't work, try exporting the plugins again
with a version you've never used before and using the
dropins folder.
Marc
> -----Original Message-----
> From: cdt-dev-bounces@xxxxxxxxxxx
> [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Tim Black
> Sent: Thursday, July 22, 2010 5:38 PM
> To: CDT General developers list.
> Subject: Re: [cdt-dev] best practices for managing a custom
> eclipse/CDT build in a C++ development organization
>
> Original plugins:
> org.eclipse.cdt.dsf.gdb_3.0.0.201006141710
> org.eclipse.cdt.dsf.gdb.ui_2.1.0.201006141710
>
> New plugins:
> org.eclipse.cdt.dsf.gdb_3.1.0.201007221231
> org.eclipse.cdt.dsf.gdb.ui_2.2.0.201007221231
>
> So, the version is different as well as the qualifier. The
> original plugins are from a standard Helios/CDT7.0 "for C/C++
> Developers" release. The new plugins were built from CDT HEAD + patch.
>
> T
>
>
> On Thu, Jul 22, 2010 at 1:12 PM, Alena Laskavaia
> <elaskavaia.cdt@xxxxxxxxx> wrote:
>
>
> What is your exported plugins qualifier looks like
> compared to original ones?
>
>
> On Thu, Jul 22, 2010 at 4:08 PM, Tim Black
> <timblaktu@xxxxxxxxx> 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
> >
> >
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cdt-dev
>
>
>
>
