[eclipse-dev] Re: [platform-ui-dev] Platform UI's plug-ins converted to

[Jeff McAffer <Jeff_McAffer@xxxxxxxxxx>]

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@xxxxxxxxxxx

04/06/2005 03:29 PM

Please respond to
dpollock and "Eclipse Platform UI component developers list."

To	platform-ui-dev@xxxxxxxxxxx
cc	eclipse-dev@xxxxxxxxxxx
Subject	[platform-ui-dev] Platform UI's plug-ins converted to manifest        format

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