[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
RE: [eclipse-dev] RCP Apps and ModifyingEclipse.org Plug-ins(forked from manifest discussion comment)
|
<g> That's what I get for skimming the first few
posts too fast. I like the promiscuous mode approach...
-- Scott
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