[
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
|
I don't understand this response. The original posting comes with a list
of six existing Eclipse-supplied plugins that possibly/probably need to
change to run under this new rule. Where is the list for external
plugins? Does it have 600 items? 6000?
We do need rules about what happens when the spec on which we are based
evolves. The first rule should be that Eclipse evolves in a way
compatible with existing plugins.
As for gratuitous, that's pretty much in the eye of the beholder. For
people whose library plugins stop working, your 5% (if the figure can be
believed) is going to seem a pretty poor tradeoff.
Bob Foster
Pascal Rapicault wrote:
The initial message is missing context. The change is not done
gratuitously:
- it brings classload speed improvement (more than 5%),
- it is part of the osgi 4.0 spec,
- it is not required by all plugins.
The solution described is the easiest to implement for library users to
minimize the disturbance, but it is however not the most optimal way.
Ideally all library plugins should import the package they use. N ote
that to date, to reuse a "library plugin with no dependencies on
Eclipse" you had to inject a plugin.xml or a manifest.mf which made the
library eclipse aware anyway.
Regarding the API, I believe that in this specific case, the question
should be how do we evolve when the spec on which we are based evolve.
It seems to me that this should falls under a specific term.
PaScaL
*Bob Foster <bob@xxxxxxxxxx>*
Sent by: platform-core-dev-bounces@xxxxxxxxxxx
05/03/05 07:23 PM
Please respond to
"Eclipse Platform Core component developers list."
To
"Eclipse Platform Core component developers list."
<platform-core-dev@xxxxxxxxxxx>
cc
Subject
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