RE: [eclipse-dev] Re: [platform-ui-dev] Platform UI's plug-insconverted

[Mike Wilson <Mike_Wilson@xxxxxxxxxx>]

It's a difficult problem. Personally, I tend to agree with Jeff. For those 
people that are doing research, or even those that just need to get a 
product out before the Eclipse community can come to a consensus on what 
some new API will look like, we really do want to allow access to non API.

Having said that, I too would like to see us move, over time, towards 
using x-internal and x-friends to accurate describe our intended uses.

McQ.




"Ed Burnette" <Ed.Burnette@xxxxxxx> 
Sent by: eclipse-dev-bounces@xxxxxxxxxxx
04/07/05 00:44
Please respond to
"General development mailing list of the Eclipse project." 
<eclipse-dev@xxxxxxxxxxx>


To
"General development mailing list of the Eclipse project." 
<eclipse-dev@xxxxxxxxxxx>
cc

Subject
RE: [eclipse-dev] Re: [platform-ui-dev] Platform UI's   plug-insconverted 
to manifest     format






Just today I had two projects fail on me when I tried to use them in 3.1M6 
(WebTools and VE) and I'm pretty sure it's because they depended upon 
internal packages that changed in M6. It's too easy to use internals by 
accident or to use them to get things working and never go back and fix it 
the right way. I've done it in my own code.
 
Therefore if I have a vote I cast it in favor of #1 for most cases. This 
a) gives developers the flexibility to change any internal package at any 
time without fear of breaking a consumer, and b) enforces a discipline of 
API usage that has been lacking up to now. 
 
If you do use #2 and/or #3, may I suggest that strict mode be the default 
for everyone, and that it be hard to turn it off, so while one developer 
or small team could be promiscuous, their code could not easily be run by 
anyone else. By 'hard' I mean don't put in UI for it, make somebody edit a 
configuration file or set a debug option or something like that.
 
Note that for RCP apps, the developer can edit the manifests or change the 
code or whatever they want so I don't think it's a big deal for them. It's 
more a big deal for add-ins to the IDE that need to work with older and 
newer IDE builds/releases.
 

From:  Jeff McAffer
Sent: Wednesday, April 06, 2005 5:25 PM
To: eclipse-dev@xxxxxxxxxxx
Subject: [eclipse-dev] Re: [platform-ui-dev] Platform UI's 
plug-insconverted to manifest format

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