> 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@eclipse.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@xxxxxxxxxxxhttps://dev.eclipse.org/mailman/listinfo/cdt-dev