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

[Mazen Faraj <mfaraj@xxxxxxxxxx>]

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: eclipse-dev-bounces@xxxxxxxxxxx

04/06/2005 05:24 PM

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

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

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