[
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
|
On 4 Aug 2010, at 22:34, Doug Schaefer <cdtdoug@xxxxxxxxx> wrote:
> We've seen issues with links and dropins. Using p2 is really the only
> safe way to install plug-ins.
In fact I've asked again and again for guidance on managing multiple
user installs -- how do I keep peoples eclipses up to date? How do I
minimise disk usage on expensive filers? And most importantly: how do
I ensure when I update a feature in some shared central p2 repository
that I don't break one of dozens of eclipses that are running
concurrently and have been for weeks...
I haven't found any answers to the above - there's no documentation on
this use case and afaics shared installs has fallen by the wayside.
With links and dropins, I can install each version of a feature in a
separate ditectory, chmod -R -r the directory, and can then guarantee
that I won't accidentally break the feature at some point in the
future.
I've had my fair share of trouble with p2, and I guess the problems I
have stem from lack of understanding. From a practical point of view,
if a team can build their project with cdt 7 + features today, they
should be able to build the same tagged source with that version of
the toolchain next year. If we cant explicitly manage versions, then
the above quickly falls apart. Big shared p2 repositories don't offer
that flexibility.
We spin a couple cdt snapshot releases a week here. With official
internal releases coming once a month or so. The same is true of the
rest of the toolchain - compilers, debuggers, and simulators. As cdt
is an Integral part of our toolchain it needs to be easy for users to
both choose versions, and guarantee that those versions will continue
to work in the future. At the moment dropins is the only way to
version orthogonal independent sets of features per user/team.
Perhaps the worlds easier if each user has a standalone IDE on her desktop :)
Cheers
James
>
> On Wed, Aug 4, 2010 at 5:03 PM, John Cortell <rat042@xxxxxxxxxxxxx> wrote:
>> I meant {eclipse}/links
>>
>> At 04:00 PM 8/4/2010, John Cortell wrote:
>>
>> An alternative to the dropins folder is the links mechanism. Basically, you
>> create a file in {workspace}/links that points Eclipse to a directory where
>> it should load features and plugins from. I am not aware of any problems
>> with that mechanism.
>>
>> http://www.ibm.com/developerworks/opensource/library/os-ecfeat/#N100B9
>>
>> John
>>
>> At 09:35 AM 7/26/2010, Marc Khouzam wrote:
>>
>> Content-Language: en-US
>> Content-Type: multipart/alternative;
>>
>> boundary="_000_F7CE05678329534C957159168FA70DEC5716B5E061EUSAACMS0703e_"
>>
>> I tried the dropins folder myself and it didn't work for me either.
>> I spoke to our release guy and he said it is safer to avoid that
>> solution all together...
>>
>> Marc
>>
>>
>>
>> ________________________________
>> From: cdt-dev-bounces@xxxxxxxxxxx [ mailto:cdt-dev-bounces@xxxxxxxxxxx] On
>> Behalf Of Tim Black Sent: Friday, July 23, 2010 4:26 PM To: CDT General
>> developers list. Subject: Re: [cdt-dev] best practices for managing a custom
>> eclipse/CDT build in a C++ development organization Now using a fresh Helios
>> SDK + CDT 7.0.0, I switched all CDT projects to Version v201006141710, i.e.
>> the identical buildstamp as CDT 7.0.0 Final, and built them. Downloaded
>> patch from May 25, 2010 and applied. There were some "unmatched hunks" and
>> the patch dialog came up, but I just told it to apply all changes and
>> rebuilt CDT.
>> * In the first test, I ran org.eclipse.cdt.ui as an Eclipse Application. As
>> before, the patch behavior is there and all is well and good. (But, per the
>> point of this thread, I want to share this change with my teammates, so I
>> need to export something...)
>> * In the next test, I exported org.eclipse.cdt.dsf.gdb and
>> org.eclipse.cdt.dsf.gdb.ui using the same version and default buildstamp
>> qualifier into a directory. Copied the .jars into dropins/ and started
>> eclipse. Same failure as before - eclipse doesn't recognize the new plugin
>> versions, and the new behavior is not there. * Repeated previous test, but
>> rebuilt plugins with a new version in the plugin.xml file - I bumped the
>> service part of the version number, so I now have org.eclipse.cdt.dsf.gdb
>> 3.0.1.qualifier and org.eclipse.cdt.dsf.gdb.ui 2.1.1.qualifier. Same failed
>> result. * Repeated previous test, but instead bumped the minor part of the
>> version number, so I now have org.eclipse.cdt.dsf.gdb 3.1.0.qualifier and
>> org.eclipse.cdt.dsf.gdb.ui 2.2.0.qualifier. Same failed result. * Repeated
>> last three tests but copied .jars into dropins/eclipse/plugins/ instead of
>> dropins/. Same failed result.
>> * Next I tried exporting my 2 modified plugins with bumped minor version
>> into the running eclipse host. Upon restart, Eclipse shows the new versions,
>> and the patch behavior is there. All is well and good! * I then reverted the
>> version to only bump the service number, thinking this more appropriate for
>> the minor change I made, so I now have org.eclipse.cdt.dsf.gdb
>> 3.0.1.qualifier and org.eclipse.cdt.dsf.gdb.ui 2.1.1.qualifier. When I try
>> to export this into running eclipse instance, I get this install error:
>> ------------------------------------------------------- Operation details
>> Your original request has been modified.
>> "org.eclipse.cdt.dsf.gdb Install Patch" is already installed, so an update
>> will be performed instead. "org.eclipse.cdt.dsf.gdb.ui Install
>> Patch" is already installed, so an update will be performed instead.
>> Cannot complete the install because one or more required items could not be
>> found. Software currently installed: C/C++ Development Tools SDK
>> 7.0.0.201006141710 (org.eclipse.cdt.sdk.feature.group 7.0.0.201006141710)
>> Missing requirement: org.eclipse.cdt.dsf.gdb Install Patch
>> 1.0.0.201007231254 (org.eclipse.cdt.dsf.gdb.patch 1.0.0.201007231254)
>> requires 'org.eclipse.cdt.dsf.gdb.ui [2.2.0.201007231242]' but it could not
>> be found Cannot satisfy dependency: From: C/C++
>> Development Tools 7.0.0.201006141710 (org.eclipse.cdt.feature.group
>> 7.0.0.201006141710) To: org.eclipse.cdt.gnu.dsf.feature.group
>> [2.1.0.201006141710] Cannot satisfy dependency: From:
>> C/C++ DSF GDB Debugger Integration 2.1.0.201006141710
>> (org.eclipse.cdt.gnu.dsf.feature.group 2.1.0.201006141710) To:
>> org.eclipse.cdt.dsf.gdb [3.0.0.201006141710] Cannot satisfy
>> dependency: From: C/C++ Development Tools SDK 7.0.0.201006141710
>> (org.eclipse.cdt.sdk.feature.group 7.0.0.201006141710) To:
>> org.eclipse.cdt.feature.group [7.0.0.201006141710]
>> --------------------------------------------------------
>> Questions/Discussion/Summary: * Any idea why I cannot export plugin into
>> running host a second time? The only change I made was to decrease the minor
>> version and increase the service version. * Either dropins/ doesn't work as
>> expected, or I'm not properly changing the plugin version. Is there
>> something else you have to do to change a plugin version number other than
>> change the plugin.xml and rebuild? The resulting .jar filenames do reflect
>> my changes but they don't seem to be getting loaded when I start eclipse...
>> * Well, I did sort of get it working in a way that is "sharable", but I have
>> to share my entire eclipse installation, which seems kind of coarse. When I
>> get time, I'll try to take the "Feature Export" approach that Marc and Chuck
>> recommended. * My newbie summary is that customizing an Eclipse installation
>> is fraught with peril, but I have found the reality is that it is very, very
>> necessary. Being able to view an STL container when debugging is a good
>> example of how something seemingly very basic can take a long time to get
>> integrated into official releases of an open source debugger and IDE. There
>> are many examples of feature that my team needs in an IDE/debugger that
>> don't seem to be getting into the main releases. (Another example is the
>> 'refresh after build' problem, which was addressed and fixed over a year ago
>> but frustratingly still did not get into CDT 7.0 for some reason.). So it
>> has been a worthwhile excercise to understand how to apply patches and
>> manage dependencies in CDT and Eclipse.
>> T
>>
>> On Fri, Jul 23, 2010 at 11:22 AM, Tim Black <timblaktu@xxxxxxxxx> wrote:
>> Trying to install CDT 8.0.0 in Helios to get exported patched cdt.dsf.gdb
>> plugins (from HEAD) to work:
>>
>> I first made a copy of my eclipse Helios+CDT7.0.1 installation and tried
>> upgrading to CDT 8.0.0 nightly build. This failed bc it recognized multiple
>> versions of org.eclipse.cdt.managedbuilder.core (said only one of 8.0.0,
>> 7.0.1, 7.0.0 can be installed at once).
>> So I started over with the standard eclipse-SDK-3.6 release and tried
>> installing CDT 8.0.0 nightly on top of that. Same error. (can't install
>> 7.0.0 and 8.0.0 at once)
>> Are these errors happening because CDT 8.0 has to be used with eclipse 3.7
>> instead of Helios? The CDT 8.0 nightly build page says it runs against
>> matching milestone build of Eclipse 3.7 only. But I wasn't able to find an
>> Eclipse 3.7 (SDK) download anywhere, although there are "3.6 stream builds"
>> with similar dates. Am I interpreting this correctly?
>> If that's the case, this means one cannot use the latest patch for Bug
>> 302121 unless they are using eclipse 3.7. Right?
>> If so, I guess I'm probably better off abandoning HEAD and trying to get
>> this working using Helios + CDT 7.0 + apply older patch to June 14th dsf.gdb
>> plugins... T
>>
>> On Fri, Jul 23, 2010 at 10:29 AM, Tim Black <timblaktu@xxxxxxxxx> wrote:
>> Thanks, Marc and everyone, for your insight and suggestions. Working with
>> and (especially) modifying Eclipse and CDT can be overwhelming, but it is a
>> pleasure to receive such rapid and thorough feedback from the development
>> team. :-) As in any complex and highly generic framework, there appear to be
>> several ways to solve a problem.
>> I aspire to cultivate a process such as Marc outlined most recently, so my
>> organization can pick up features (sorry, I know this word is overloaded
>> here...) as they are added to the 7.0 branch over time without having to
>> deal with the instability of HEAD. And btw, ftr it seems this process is
>> very close to the one described earlier by Chuck Wilson. Except that Chuck
>> uses the 7.0 tag instead. And he mentioned creating a Feature Project (which
>> I don't know anything about yet...)
>> Choosing a starting point for a custom, patched CDT build seems to depend on
>> what patches or modifications you need to apply. Not being much of a java
>> programmer myself, I mostly rely on (leech off?) the patches created by
>> others. So for me, I must choose the starting point that requires the least
>> amount of manual modifications to apply patches of interest. And not
>> understanding the architecture of CDT, I find it difficult to determine
>> dependencies between patches and CDT code - afaik the date of the patch is
>> all I have to go on. And because the changes within a patch reflect changes
>> to files from several different dates, there's a lot of guesswork at
>> determining what CVS location to start from. (for me, at least)
>> Is it true that most patches are written to apply to/work with HEAD at the
>> time, with the intent being that they will get merged into HEAD? If so, this
>> motivates me to stay on the bleeding edge, but I have had problems building
>> from HEAD before (for days at a time), so I'd have to be prepared for that..
>> Thanks again. I'll report back when I have more results. T
>>
>> On Fri, Jul 23, 2010 at 6:07 AM, Marc Khouzam < marc.khouzam@xxxxxxxxxxxx>
>> wrote: I jumped in a little late on the thread but I thought I'd tell you
>> what we've been doing internally for a similar situation, where we've needed
>> to release a patched CDT to our users. It's been working pretty well for
>> us.
>> We take the 7_0 branch since it is less 'in flux' than HEAD, we patch it
>> with the features we need extra, and we do an entire CDT build. Here are the
>> steps:
>> 1- Install an Helios release of the platform (no CDT) 2- Check out the list
>> of plugins below from the branch cdt_7_0 3- Change the version of every
>> feature.xml file checkedout (this is a bit of a mystery to me) 4- Patch
>> the code with whatever changes you need. Those changes _must_ be
>> compatible with cdt_7_0, so you need to pick your patches carefully, or
>> adapt them. 5- Once everything is compiled and tested, you should export the
>> CDT features. This must be done on the same type of machine as were
>> your users will run it (e.g., Linux64, Windows, etc) 6- right-click on any
>> plugin and choose Export... 7- Select "Deployable Features" under "Plugin
>> development" 8- You only need to check org.eclipse.cdt. 9- Choose the
>> Destination to be a zip file of your choice 10- The resulting zip file can
>> be used to install you own version of CDT on top of Helios.
>> Plugins I checkout to build CDT: org.eclipse.cdt/ org.eclipse.cdt.core/
>> org.eclipse.cdt.core.aix/ org.eclipse.cdt.core.linux/
>> org.eclipse.cdt.core.linux.ia64/ org.eclipse.cdt.core.linux.ppc/
>> org.eclipse.cdt.core.linux.x86/ org.eclipse.cdt.core.linux.x86_64/
>> org.eclipse.cdt.core.macosx/ org.eclipse.cdt.core.qnx/
>> org.eclipse.cdt.core.solaris/ org.eclipse.cdt.core.win32/
>> org.eclipse.cdt.debug.core/ org.eclipse.cdt.debug.mi.core/
>> org.eclipse.cdt.debug.mi.ui/ org.eclipse.cdt.debug.ui/
>> org.eclipse.cdt.doc.isv/ org.eclipse.cdt.doc.user/ org.eclipse.cdt.dsf/
>> org.eclipse.cdt.dsf.gdb/ org.eclipse.cdt.dsf.gdb.ui/ org.eclipse.cdt.dsf.ui/
>> org.eclipse.cdt-feature/ org.eclipse.cdt.gdb/ org.eclipse.cdt.gdb-feature/
>> org.eclipse.cdt.gdb.ui/ org.eclipse.cdt.gnu.build-feature/
>> org.eclipse.cdt.gnu.debug-feature/ org.eclipse.cdt.gnu.dsf-feature/
>> org.eclipse.cdt.launch/ org.eclipse.cdt.make.core/ org.eclipse.cdt.make.ui/
>> org.eclipse.cdt.managedbuilder.core/ org.eclipse.cdt.managedbuilder.gnu.ui/
>> org.eclipse.cdt.managedbuilder.ui/ org.eclipse.cdt.p2/
>> org.eclipse.cdt.p2-feature/ org.eclipse.cdt.p2.generator/
>> org.eclipse.cdt.platform-feature/ org.eclipse.cdt.sdk/
>> org.eclipse.cdt.sdk-feature/ org.eclipse.cdt.ui/
>> Below are optional plugins if you want other features. You would need to
>> also select the checkbox for their feature when exporting since they are not
>> part of the main CDT feature.
>> GDB harware debugging: org.eclipse.cdt.debug.gdbjtag/
>> org.eclipse.cdt.debug.gdbjtag.core/ org.eclipse.cdt.debug.gdbjtag-feature/
>> org.eclipse.cdt.debug.gdbjtag.ui/
>> Enhanced memory feature for debugging:
>> org.eclipse.cdt.debug.ui.memory-feature/
>> org.eclipse.cdt.debug.ui.memory.memorybrowser/
>> org.eclipse.cdt.debug.ui.memory.search/
>> org.eclipse.cdt.debug.ui.memory.traditional/
>> org.eclipse.cdt.debug.ui.memory.transport/
>> And there is also CODAN, EDC and probably other features that I'm not very
>> familiar with. Marc
>>
>>> -----Original Message----- > From: cdt-dev-bounces@xxxxxxxxxxx > [
>>> mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Marc Khouzam > Sent:
>>> Friday, July 23, 2010 7:04 AM > To: CDT General developers list. > 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
>>
>>
>>
>>
>> _______________________________________________
>> 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
>>
>>
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cdt-dev
