Re: [platform-core-dev] Bundles which do not require org.eclipse.osgi

[Bob Foster <bob@xxxxxxxxxx>]

It's not really obvious what makes sense about it. Any plugin that is 
essentially a library plugin with no dependencies on Eclipse might break 
with this change. What benefit makes this risk worthwhile?

It gets back to, what does "API" mean in Eclipse? In the rest of the 
world, an API is a contract, which usually means something written down. 
But so little is written down about the Eclipse contract, e.g., 
virtually nothing about plugin class loading except an obsolete article, 
that developers are forced to rely on implied contracts - such as, a 
plugin classloader will have access to anything the boot classloader 
does. Sadly, it seems rare that such an implied contract is honored by a 
committer. This situation seems to encourage poor documentation; to 
preserve maximum flexibility, a developer is best off saying nothing at 
all. Then, when they pull the rug out from under some developer who was 
forced to read the code even to find out what the heck some API does 
(the Search API leaps to mind) they can claim "not API". What API?

Bob Foster

Philippe Ombredanne wrote:
> Non re-exporting all makes sense.
> It would be interesting to see/know how many external (non eclipse
> provided plug-ins) it will break.
>
> --
> Cheers
> Philippe
>
> philippe ombredanne | nexB - Open by Design (tm)
> 1 650 799 0949 | pombredanne at nexb.com
> http://www.nexb.com 
> -----Original Message-----
> From: platform-core-dev-bounces@xxxxxxxxxxx
> [mailto:platform-core-dev-bounces@xxxxxxxxxxx] On Behalf Of Thomas
> Watson
> Sent: Tuesday, May 03, 2005 1:02 PM
> To: platform-core-dev@xxxxxxxxxxx
> Subject: [platform-core-dev] Bundles which do not require
> org.eclipse.osgi
>
>
>
> In this week I-Build the OSGi framework no longer gives access to
> non-java.* packages provided by the JVM for free.  Previously we used to
> always delegate to the boot classloader before delegating to OSGi for
> all class loads.  This means non-java.* packages (i.e. java.xml.parsers)
> are not accessible unless the bundle imports the package (using
> Import-Package: java.xml.parsers) or requires the system.bundle (using
> Require-Bundle: org.eclipse.osgi).  Most bundles in eclipse require
> org.eclipse.osgi indirectly because they require
> org.eclipse.core.runtime which reexports org.eclipse.osgi.  This means
> most bundles in eclipse do get access to the packages provided by the
> JVM profile.  The following bundles do not require org.eclipse.osgi
> directly or indirectly. 
>
> org.apache.ant 
> org.apache.lucene 
> org.eclipse.core.boot 
> org.eclipse.jdt 
> org.eclipse.jdt.doc.isv 
> org.eclipse.jdt.doc.user 
> org.eclipse.jdt.junit.runtime 
> org.eclipse.jdt.source 
> org.eclipse.pde.doc.user 
> org.eclipse.pde.source 
> org.eclipse.platform 
> org.eclipse.platform.doc.isv 
> org.eclipse.platform.doc.user 
> org.eclipse.platform.source 
> org.eclipse.sdk 
> org.eclipse.swt 
> org.eclipse.text 
> org.junit 
>
> I suspect the following bundles should require the org.eclipse.osgi
> bundle incase they access any non-java.* packages from the JVM: 
>
> org.apache.ant 
> org.apache.lucene 
> org.eclipse.swt 
> org.eclipse.text 
> org.junit 
>
> The rest of the bundles which do not require org.eclipse.osgi do not
> have any actual code in them so there is no need to require anything.  I
> want to get confirmation from the core team that we think this is
> necessary before I post to the general eclispe dev mailing list
> requesting these bundles update their manifests to Require-Bundle:
> org.eclipse.osgi. 
>
> Thomas Watson
>
> _______________________________________________
> platform-core-dev mailing list
> platform-core-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/platform-core-dev