Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [cross-project-issues-dev] Jars in jars is good citicenship?

Fyi, the following bug is the same story, and I regularly hear about new
plug-in developers getting confused by this since Equinox supports it and
PDE doesn't.

157375: PDE should support building against nested JARs


> -----Original Message-----
> From: cross-project-issues-dev-bounces@xxxxxxxxxxx [mailto:cross-
> project-issues-dev-bounces@xxxxxxxxxxx] On Behalf Of Ed Merks
> Sent: Friday, November 02, 2007 4:19 AM
> To: Cross project issues
> Cc: Cross project issues; cross-project-issues-dev-bounces@xxxxxxxxxxx
> Subject: Re: [cross-project-issues-dev] Jars in jars is good
> citicenship?
> Thomas,
> It seems to me we've run into this kind of issue too with
> org.eclipse.emf.ant where org.eclipse.uml2.uml.ecore.importer extends
> those
> tasks and while the build worked fine in the development environment,
> the
> PDE build building UML2 against the packaged build result of EMF has
> problems.  I think we needed to hack the build to unjar the plugin; or
> maybe we did something worse.  I've never consider what impact this had
> on
> other clients who might want to extend our tasks...
> I've certainly been frustrated that
> never gets
> addressed
> because JDT needs to address
> which can't be
> done
> without some kind of hooks in the Resource implementation, and that
> never
> gets done for a reason I can no longer remember.  I'm not really sure
> why
> your particular issue couldn't be addressed given that installed jarred
> plugins with nested jars are often exploded and then the nested jar is
> available directly in the file system.  I suppose this is naive
> thinking in
> that this applies only if the jar is actually the one in the running
> environment itself.  In your case, are the non-Ant classes jarred up in
> a
> different jar that is also a nested jar in the jar?  In our case, we
> really
> have to jar the plugin or we get stuck with the problem I just
> mentioned.
> I suppose we could have not jarred the plugin and produced two jars
> too,
> but we didn't recognize the problem with the Ant jar until longer after
> we
> made the choice....
> It seems to me if the compiler issue can't be fixed, we'd need to at
> least
> consider making exceptions...
> Ed Merks/Toronto/IBM@IBMCA
> mailto: merks@xxxxxxxxxx
> 905-413-3265  (t/l 313)
>              Thomas Hallgren
>              <thomas@xxxxxxx>
>              Sent by:
> To
>              cross-project-iss         Cross project issues
>              ues-dev-bounces@e         <cross-project-issues-
> dev@eclipse.o
>                    rg>
> cc
>              11/02/2007 06:52
> Subject
>              AM                        [cross-project-issues-dev] Jars
> in
>                                        jars is good citicenship?
>              Please respond to
>                Cross project
>                   issues
>              <cross-project-is
>              sues-dev@eclipse.
>                    org>
> 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
> _______________________________________________
> cross-project-issues-dev mailing list
> cross-project-issues-dev@xxxxxxxxxxx

Back to the top