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

[Jeff McAffer <Jeff_McAffer@xxxxxxxxxx>]

This is the poster child for my original
post suggesting that people should do 2, 3 or 4 as appropriate.  This
allows people to use promiscuous mode and see everything if they want to.
 If someone uses 1, there is no hope.

Jeff

"Scott Stanchfield" <scott@xxxxxxxxxxxx>
Sent by: eclipse-dev-bounces@xxxxxxxxxxx

04/07/2005 12:58 PM

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

To	"'General development mailing list of the Eclipse project.'" <eclipse-dev@xxxxxxxxxxx>
cc
Subject	RE: [eclipse-dev] RCP Apps and Modifying Eclipse.org        Plug-ins(forked        from manifest discussion comment)

<g> I guess I interpreted
things correctly...
 
Two weeks ago I discussed the
Facade pattern with my design patterns students @ Hopkins. Whenever I do
that lecture, I bring up the difference between using public/non-public
in a single package to delineate the lib API, and between using package
naming conventions to convey the meaning.
 
Of course Eclipse is the prime
example of the latter, (and I and my students really appreciate it). I
hope this can be loosened back to the way it was. Put the onus on the guys
who use internals. If their plugins break, it's their problem...
 
If people don't want to accidentally
use internals, let them use the compiler warning/error feature. (Damn I
love that compiler, gang! Beauty! Options galore! Woohoo!)
 
That's my 2cp anyway...
 
Later,
-- Scott

---

From: eclipse-dev-bounces@xxxxxxxxxxx
[mailto:eclipse-dev-bounces@xxxxxxxxxxx] On Behalf Of Scott Fairbrother
Sent: Thursday, April 07, 2005 12:31 PM
To: General development mailing list of the Eclipse project.
Subject: Re: [eclipse-dev] RCP Apps and Modifying Eclipse.org Plug-ins(forked
from manifest discussion comment)


Hi Jeff - 

I have seen enough data points to suggest this is not a fringe case.  There
is and has been a significant number of enhancement requests, from good
Eclipse citizens to make internal interfaces API.  Some citizens are
willing to wait for API,  while for others, waiting is not an option,
because of time to market pressures.  I have seen cases where some
copy the code while others, accept the risk, and  run with the internal
plug-in package references.  While there are problems with either
approach, it's a safe bet that there is a lot of this going on.  
    

Thanks,
Scott Fairbrother
Eclipse/WebSphere Studio Jumpstart Team
607 Pinewood Dr
Apex , NC 27502

Voice : 919-367-9345  TL:  223-7851

The Java Developer's Guide to Eclipse - http://www.aw.com/catalog/academic/product/1,4096,0321159640,00.html?type=PRE
Ready for Rational Software partner program - http://www.developer.ibm.com/rational/readyfor.html

Jeff McAffer <Jeff_McAffer@xxxxxxxxxx>
Sent by: eclipse-dev-bounces@xxxxxxxxxxx

04/07/2005 11:51 AM

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

To	"General development mailing list of the Eclipse project." <eclipse-dev@xxxxxxxxxxx>
cc
Subject	Re: [eclipse-dev] RCP Apps and Modifying Eclipse.org Plug-ins (forked        from manifest discussion comment)

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
_______________________________________________
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
_______________________________________________
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