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

[Jeff McAffer <Jeff_McAffer@xxxxxxxxxx>]

We are reviewing how Eclipse can take
advantage of the OSGi R4 spec opportunities for greater portability and
performance while providing the best possible developer experience.

Jeff

Randy Hudson <hudsonr@xxxxxxxxxx>
Sent by: platform-core-dev-bounces@xxxxxxxxxxx

05/04/2005 05:37 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

Will the PDE reflect this new behavior in its classpath calculations?

-Randy

Jeff McAffer <Jeff_McAffer@xxxxxxxxxx>
Sent by: platform-core-dev-bounces@xxxxxxxxxxx

05/04/2005 04:41 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

Some clarification... 

This is absolutely NOT a backward compatibility issue.  ALL "old"
plugins continue to run fine and are NOT affected by this change.  An
"old" plugin is one that either does not have a manifest.mf or
does not have "Bundle-ManifestVersion: 2" in its manifest. 

This issue affects only bundles that have moved to the new syntax and semantics
of Bundle-ManifestVersion: 2.  For perspective, the earliest that
anyone would have become a "new" plugin is about M5.  Eclipse
proper only picked this up only as people were massaging their plugins
(JARing and updating manifests) in the last month or so.  The summary
is that this issue is very localized. 

Having said that, we are reviewing how Eclipse can take advantage of the
OSGi R4 spec opportunities for greater portability and performance while
providing the best possible developer experience.  

Jeff

Jim des Rivieres/Ottawa/IBM@IBMCA
Sent by: platform-core-dev-bounces@xxxxxxxxxxx

05/03/2005 11:18 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

> In this week I-Build the OSGi framework no longer gives access to
> non-java.* packages provided by the JVM for free. 

Thomas,  A change that would result in the Java class libraries no
longer 
being visible would cause major breakage to existing Eclipse plug-ins.
We 
need to ensure that existing Eclipse 3.0 plug-ins in the field continue
to 
work in 3.1. 

---jim




Bob Foster <bob@xxxxxxxxxx> 
Sent by: platform-core-dev-bounces@xxxxxxxxxxx
05/03/2005 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


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