[
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.
As a counter to this, we've been using dropins with links successfully
since 3.5. It's the _only_ way to support shared install where
different users can choose different feature sets without each user
having a copy of the plugins copied into their writeable configuration
wasting disk space.
Sometimes weird things happen to configurations during reconciling,
but it's usually an admin error -- ie some of my the feature sets are
incompatible... However all in all it's worked pretty well for us.
We use a simple shell script for users to manage the features they
want installed:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=305642
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
