> 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