[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
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
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