Re: [eclipse-dev] RCP Apps and Modifying Eclipse.org Plug-ins (forked fr

[Jeff McAffer <Jeff_McAffer@xxxxxxxxxx>]

First choice in these cases (which I
full acknowledge) is to COPY the relevant bits.  If that means copying
the whole plugin and hacking out what you don't want, ok.  Changing
the plugin in-place is completely against the notion of modularity and
component that we are trying so hard to put forward in Eclipse (or any
other component system for that matter).   How will you or anyone
else tell the difference between you org.eclipse.ui.ide_3.1.0.jar that
has been hacked and the original?  you can change the version but
people match on a coarser grain than that.  You will never be able
to add some other plugin to the system that needs the real ui.ide plugin.

Again, if you are in a closed world,
then go for it.  Otherwise, run screaming as fast as you can.

Jeff

p.s., What I am really trying to say
is "yes, this might happen sometimes but is should not be 'the solution'
to problems people have wrt API and manifest declarations.  This is
a very fringe case and this approach leads to brittle systems".

Pat McCarthy <patmc@xxxxxxxxxx>
Sent by: eclipse-dev-bounces@xxxxxxxxxxx

04/07/2005 10:53 AM

Please respond to
"General development mailing list of the Eclipse project."

To	eclipse-dev@xxxxxxxxxxx
cc
Subject	[eclipse-dev] RCP Apps and Modifying Eclipse.org Plug-ins (forked from manifest discussion comment)

Jeff said: 
>>What do you mean about being able to edit plugins for RCP apps.
 Are you 
>>suggesting that people go and modify the code or manifests for
other 
>>plugins?  While techincally possible this is definitely not
recommended. 
>>Its not clear what that capability has to do with RCP apps either.
 If you 
>>modify some plugin you don't own, you basically void its warranty/testing
>>and potentially impact all other consuming plugins.  Sure,
if your app 
>>(RCP or otherwise) is completely closed or under your control,
knock 
>>yourself out.  This is not a practice I would feel comfortable
promoting 
>>or relying on. 

I'm in line with Ed as you can't get what you want/need (which is always
defined by the builder of an RCP app) with the current packaging of Eclipse.

Some actually want quite a bit of the native workbench function (without
core.resource) in their application. 
Best way to learn how to run/add much of this is to explore the Eclipse
IDE version of a WorkbenchAdvisor and find ways of adding common menu tree's
back into a private RCP application. 
But what you want is not always ready/where you want it.

Examples: 
Wanting to add parts of the Update Manager triggered bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=84695.

Adding in the common Preferences dialog, and having a decent set of plug-ins
(RCP base+ui.views+private code) nets out to exactly ZERO pref pages. Where
are the common pages for Workbench Appearance, Colors/Fonts, and so on?
 In the org.eclipse.ui.ide plug-in of course (not where we can reuse
them without bringing in a bit more than we want from that plug-in).

I'm sure Ed can/has added to this list. 

What are the chances of getting things that are not quite IDE specific
(like general purpose preference pages) in a plug-in such that we don't
have to hack apart ui.ide to get them in our Workbench-like RCP applications?


Pat McCarthy   --       
                    
       --   Visit http://www.jdg2e.com/  
              _______________________________________________
eclipse-dev mailing list
eclipse-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/eclipse-dev