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

[Pascal Rapicault <Pascal_Rapicault@xxxxxxxxxx>]

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
> 
> _______________________________________________
> platform-core-dev mailing list
> platform-core-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/platform-core-dev
> 
> 


_______________________________________________
platform-core-dev mailing list
platform-core-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/platform-core-dev