There are always some exceptions to
this rule; not all plugins can be shipped as JARs when there are runtime
constraints that prevent it from working. The platform itself has several
plugins that fall into this category that are not shipped as jars.
Having said that, altering the runtime
structure of plugins to workaround development time limitations seems to
be a poor reason for not doing this valuable optimization. It's certainly
not the case that all plugins that contain nested jars cannot be jarred.
In the case of nested jars that contain ant tasks, downstream plugins don't
typically need to reference the Java code that implements the tasks, so
they don't need to appear on the development time classpath of downstream
plugins (Ed's case of subclassing tasks is perhaps an exception to this).
If you really have a case that links
and runs fine at runtime, but fails to compile at development time, I suggest
entering a bug against PDE to see if they can support it better.
Thomas Hallgren <thomas@xxxxxxx> Sent by: cross-project-issues-dev-bounces@xxxxxxxxxxx
11/02/2007 06:52 AM
Please respond to
Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>
[cross-project-issues-dev] Jars in jars
is good citicenship?
I have a question regarding the "Should Do item
#1 "Projects should have
jar'ed plug-ins because this is good Eclipse citizenship"
I think this creates problems for downstream projects that have
dependencies on these jars when the plug-ins themselves contains other
jars. The eclipse runtime can handle this but the compiler can't. Here's
a use case (using a component that is not part of Ganymede, but anyway)
that highlights this.
I'm developing the Subclipse plug-in for Buckminster. It is dependent on
the org.tigris.subversion.subclipse.core. This plug-in is only available
as a jar'ed plug-in that in turn contains other jars and this is the
cause for some headache.
I have it installed in my IDE (or in my target platform) but I still get
compilation errors. The remedy is to import the plugin into my
workspace. When I do that, and the compiler errors disappear.
Unfortunately, now I break the self-hosting instead. So I need to
handcraft the bundle selection in my launcher and specify that this
bundle must be picked from the target platform rather then from my
workspace. Now everything works fine.
I've been told that since all jars that are needed are available as OSGi
bundles in Orbit, this problem doesn't exist. No jars in jars construct
is ever needed. I think there are exceptions to that rule. A bundle that
provides Ant tasks for instance, needs to keep them separate from what's
seen by the bundle classloader and hence, must use the jars in jars
mechanism. Perhaps there are other cases that I'm not aware of.
My point is, perhaps "Should Do item #1" should be changed to
that doesn't produce plug-ins that themselves contain jars should have
jar'ed plug-ins because this is good Eclipse citizenship"?
cross-project-issues-dev mailing list