Re: [cross-project-issues-dev] Jars in jars is good citicenship?

[John Arthorne <John_Arthorne@xxxxxxxxxx>]

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.

John

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>

To	Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>
cc
Subject	[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
"Projects 
that doesn't produce plug-ins that themselves contain jars should have
jar'ed plug-ins because this is good Eclipse citizenship"?

Regards,
Thomas Hallgren

_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev