[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [platform-core-dev] Bundles which do not require org.eclipse.osgi
|
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