> Subject: RE: [cdt-dev] best practices for managing a custom
> eclipse/CDT build in a C++ development organization
>
>
> ________________________________
> From:
cdt-dev-bounces@xxxxxxxxxxx
> [
cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Tim Black
> [
timblaktu@xxxxxxxxx]
> Sent: July 22, 2010 6:50 PM
> To: CDT General developers list.
> Subject: Re: [cdt-dev] best practices for managing a custom
> eclipse/CDT build in a C++ development organization
>
> About reusing version numbers, I haven't manually or
> intentionally changed any version numbers when exporting
> plugins, except for the qualifier, which is automatically
> updated on export. The version bump I assume occurred between
> CDT7.0 and HEAD.
>
>
>
> Each time you want to use the dropins folder you must update
> the version of each plugin to something that the eclipse
> installation has never seen before. I think updating the
> minor version is enough.
>
>
> Marc, I see that you're actively involved in the discussion
> for Bug 302121, which contains the patch I'm using. Would you
> happen to know what snapshot of CDT I should get to apply
> this patch? I don't understand how to determine what CVS
> tag/HEAD to use for any given patch. As I mentioned, I used
> CDT HEAD at first, because I knew the patch was very recent.
> The patch applied and built and seemed to work when I tested
> using self-hosting, so I thought HEAD was the right choice.
> Should I try rebuilding them from 7.0?
>
>
>
> For HEAD you should use the patch posted on the 16th of July.
>
> Re-building from 7.0 would be just as tricky because the code
> in the 7_0 branch has also changed since Helios and you would need
>
> to update it all anyway. The value of using 7_0 is that is
> may be more stable than HEAD since it got less changes. For
> a deployment
>
> that may be better.
>
>
>
> Another thing you could do is to check out
> org.eclipse.cdt.dsf.gdb and org.eclipse.cdt.dsf.gdb.ui which
> are compatible with Helios.
>
> I'm not sure what the proper way to do this is, maybe someone
> else knows. One way you could do this is to check out based on a
>
> date, which would be June 14th. If you check out those two
> plugins as they were on June 14th, you will be able to deploy them
>
> directly on a Helios release.
>
>
>
> If you do get the June 14th of those two plugins, you should
> patch them using the patch of bug 302121 of May 25th (notice it is
>
> marked at obsolete simply because it no longer applies to HEAD.)
>
>
>
> Marc
>
>
>
>
>
>
> I will try the dropins/eclipse/plugins suggestion...
>
> T
>
> On Thu, Jul 22, 2010 at 3:04 PM, Marc Khouzam
> <
marc.khouzam@xxxxxxxxxxxx<mailto:
marc.khouzam@xxxxxxxxxxxx>> wrote:
>
> > 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>
> >
> [mailto:
cdt-dev-bounces@xxxxxxxxxxx<mailto:
cdt-dev-bounces@ecl
ipse.org>] 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<mailto:
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<mailto:
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<mailto:
jamesblackburn@xxxxxxxxx>>
> > > wrote:
> > >>
> > >>
> > >> On 22 July 2010 10:21, Beth Tibbitts
> > <
tibbitts@xxxxxxxxxx<mailto:
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<mailto:
cdt-dev@xxxxxxxxxxx>
> > >>
https://dev.eclipse.org/mailman/listinfo/cdt-dev
> > >>
> > >
> > >
> > > _______________________________________________
> > > cdt-dev mailing list
> > >
cdt-dev@xxxxxxxxxxx<mailto:
cdt-dev@xxxxxxxxxxx>
> > >
https://dev.eclipse.org/mailman/listinfo/cdt-dev
> > >
> > >
> > _______________________________________________
> > cdt-dev mailing list
> >
cdt-dev@xxxxxxxxxxx<mailto:
cdt-dev@xxxxxxxxxxx>
> >
https://dev.eclipse.org/mailman/listinfo/cdt-dev
> >
> >
> >
> > _______________________________________________
> cdt-dev mailing list
>
cdt-dev@xxxxxxxxxxx<mailto:
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
