| Separation of Java and Eclipse Worlds [message #512716] |
Sat, 06 February 2010 13:01  |
Eclipse User |
|
|
|
I know the answers to all my questions deal with the lazy loading of plugins, but am wondering if there is something I am overlooking that addresses these issues:
Is there a way to use a plain java library/jar without exposing it through a plugin? Or an easier way to expose a jar without rebuilding the plain java library (which is also used outside the eclipse world) for those projects and then also rebuilding the Eclipse plugin?
Is there a method of making Java SPI work? In the past I've worked around this by using Eclipse extension points - but it feels more difficult than it should be.
In general I feel I've been burned many times by the way Eclipse class loading works - maybe I'm missing some fundamental details. Are there any good articles that address the differences between OSGI/Eclipse loading and regular java class loaders, or explain how eclipse loading works in detail?
Thanks,
Jared
|
|
|
| Re: Separation of Java and Eclipse Worlds [message #513001 is a reply to message #512716] |
Mon, 08 February 2010 09:36  |
| Eclipse User |
|
|
|
There are a number of articles talking about OSGi classloading, and
there are probably another set that deal specifically with Eclipse and
classloading (extension points, etc).
The fundamental statement for OSGi is "bundles can only see other
bundles". You either have to require another bundle (promoted mostly be
eclipse) or import the other bundles packages (which it exports,
favoured in the OSGi world).
How to manage them depends on your scenario: Are you developing the 3rd
party jar and the eclipse plugin together? Are you simply consuming a
3rd party jar (org.apache.commons.lang-2.4.0.jar)?
If you want to work on a java project that should also be consumed as an
OSGi bundle, that's easy to set up in eclipse (SWT is like that, and is
usable from within eclipse both for a java app and as a plugin library).
If you want to consume a generic java project that doesn't use
reflection, then you have 2 choices ... either turn the jar into a
bundle (by adding the appropriate OSGi MANIFEST.MF entries) or create a
bundle that includes the jar in question and exports it appropriately.
Option 1 changes the 3rd party jar (although not much) and option 2 you
aren't modifying the 3rd party jar.
If you want to consume a java library that uses reflection, that's
harder ... it depends on a flat classpath, but OSGi provides modularity
imposed on the classpath. Then you have to pick the appropriate
workaround for the type of java library that it is (and it really
depends on what the java library is trying to do).
Extension points allow contributors to extend a bundles basic
functionality (and handle the classloading for you). In the OSGi world
I would imagine you get the same effect from implementing a common
interface and having contributors register their contributions as a
service (the whiteboard pattern is the common example I can think of).
I know this is more of a rambling description rather than a clear answer
to your question, but it really does depend on which OSGi vs Java
library problem you are trying to solve.
PW
--
Paul Webster
http://wiki.eclipse.org/Platform_Command_Framework
http://wiki.eclipse.org/Command_Core_Expressions
http://wiki.eclipse.org/Menu_Contributions
http://wiki.eclipse.org/Menus_Extension_Mapping
http://help.eclipse.org/galileo/index.jsp?topic=/org.eclipse .platform.doc.isv/guide/workbench.htm
|
|
|
Powered by
FUDForum. Page generated in 0.04077 seconds
Home