Skip to main content

[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

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> 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>
> wrote:
>>
>>
>> On 22 July 2010 10:21, Beth Tibbitts <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
>> https://dev.eclipse.org/mailman/listinfo/cdt-dev
>>
>
>
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cdt-dev
>
>


Back to the top