[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [eclipse-dev] Re: [platform-ui-dev] Platform UI's plug-ins converted to manifest format
|
In general, when you want to illustrate an example about friends, please
use plugin id's like 'rachel', 'chandler' and 'monica' instead of 'bar'.
This way it would be easier to relate to :-)
Wassim.
Mazen
Faraj/Toronto/IBM
@IBMCA To
Sent by: eclipse-dev@xxxxxxxxxxx
eclipse-dev-bounc cc
es@xxxxxxxxxxx
Subject
Re: [eclipse-dev] Re:
04/07/2005 11:29 [platform-ui-dev] Platform UI's
AM plug-ins converted to manifest
format
Please respond to
"General
development
mailing list of
the Eclipse
project."
just something that occured to my mind....
While this (meaning ;x-friends: and ;x-internal:=true) is all goodness and
beautiful, it seems that if a plugin really wants to make use of it, the
plugin needs to have some knowledge of upward plugins/products that will
depend on it. Meaning, if I did not know that plugin bar depended on me, I
would never right:
org.eclipse.foo;x-friends:="org.eclipse.bar"
In the wildest dreams, is there a chance that these contributions are done
the other way round? meaning, it is plugin Bar that declares that it needs
plugin foo? Im sure there are api and runtime design implications for this,
but think about it.... its plugin Bar that decided to use internals from
plugin foo, so why should plugin foo have to do the work. Plus, this forces
plugin Bar to always have a list of other plugins they have cracked open
and used internals from.
Life for plugin Foo is unaffected, and is unaware of Bar's existance.
Mazen.
Jeff
McAffer/Ottawa/IBM@IBMCA
Sent by: To
eclipse-dev-bounces@eclips eclipse-dev@xxxxxxxxxxx
e.org cc
Subject
04/06/2005 05:24 PM [eclipse-dev] Re:
[platform-ui-dev] Platform UI's
plug-ins converted to
Please respond to manifest format
"General development
mailing list of the
Eclipse project."
This raises an interesting question. "What is the Eclipse SDK team's
convention of exposing packages?"
There are four states a package can be in
1) omitted from the Export-Package list - in this case the package is just
plain not visible to other plugins. Ever.
2) Export-Package: org.eclipse.foo;x-internal:=true - in this case the
package is available if PDE or Runtime (whichever is relevant) is in
"promiscuous" mode. In "strict" mode this state is equivalent to #1.
3) Export-Package: org.eclipse.foo;x-friends:="org.eclipse.bar" - In
promiscuous mode foo is available to all. In strict mode foo is only
available to plugin b. This is equivalent to the two plugins being members
of the same "component" in component.xml terms
4) Export-Package: org.eclipse.foo - this is an unqualified export and
allows all other plugins the opportunity to see the contents of foo in all
modes.
The current Eclipse approach then translates into:
All packages listed as in one of #2, 3 or 4 and running in
promiscuous mode.
There have been some proposals (as Doug's) that would see some packages in
state #1 (not listed). In this case the omitted packages will never be
available to anyone. This is good from an API point of view but is
problematic for others.
Eclipse is used in many different ways by many different people. Some are
shipping products and care about API, some are doing research and want/need
to grovel/hack and still others are just trying to solve their problem.
Choosing to omit packages from the Export-Package list impedes the latter
two groups from succeeding with Eclipse. In some cases this may inhibit
innovation and experimentation with things like aspects, new UI models,
etc.
Proposal:
As an SDK-wide convention ALL plugins should list ALL packages on their
Export-Package list. As teams analyze their API relationships and create
their component.xml files they can mark up the exports with "x-internal or
"x-friends" as appropriate. This gives developers the best of both
worlds -- those who care can develop in strict mode and get immediate
feedback if they break the rules. Those who are fine the risks and
downsides of can use promiscuous mode and make progress.
Perhaps more important than any of this is some level of consistency across
the SDK plugins. Having some plugins omit some of their packages and
others list ones with similar characteristics sends a confusing message to
developers.
Jeff
Douglas Pollock
<douglas.pollock@xxxxxxxx>
Sent by:
platform-ui-dev-bounces@eclipse.o To
rg platform-ui-dev@xxxxxxxxxx
g
cc
04/06/2005 03:29 PM eclipse-dev@xxxxxxxxxxx
Subject
[platform-ui-dev] Platform
Please respond to UI's plug-ins converted to
dpollock and "Eclipse Platform manifest format
UI component developers list."
I believe that all of the plug-ins maintained by the Platform/UI team have
now
been converted to the manifest format.
Where possible, I have blocked access to internal packages that were added
during the 3.1 development cycle. Internal packages that were added during
3.0 or earlier are still exposed (though you shouldn't be using them).
Internal packages added during 3.1 that could not be blocked are covered by
Bug 90512 ("https://bugs.eclipse.org/bugs/show_bug.cgi?id=90512";).
If you have any problems, please file bugs.
thanks,
d.
_______________________________________________
platform-ui-dev mailing list
platform-ui-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/platform-ui-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
