Exporting a jar from Eclipse with more jar's *in* it...

[Joe Emenaker]

I'm writing a Java app in Eclipse. It uses some third-party jars,
which I have in my Eclipse workspace.

When I export my jar, Eclipse packs all of my class files AND all of
the jars I'm using into my exported jar. Okay... great.

However, when I try to run the jar after that, I get
NoClassDefFoundError's when it comes time to instantiate a class
that's in one of the "inner" jars.

I guess I could distribute the third-party jars separately, but then I
need to provide the user with a way to set the classpath when they run
the app (which means platform-independent "run" scripts). To get
around *that*, I guess I could unpack all of the jars into my compile
"bin/" directory with the rest of *my* stuff, but then that gets stuff
all mixed up.

Is there a way to get Eclipse to magically package a single jar which
would set the classpath to point to the jars *within* my jar (or is
that even possible with the Sun J2RE)?

If not, what's the best way that people have found to get past this
problem?

Thanks,
- Joe

 

[Andrew Thompson]

I'm writing a Java app in Eclipse. It uses some third-party jars,
which I have in my Eclipse workspace.

When I export my jar, Eclipse packs all of my class files AND all of
the jars I'm using into my exported jar. Okay... great.

That's three times you've mentioned Eclipse..

Do it from the command line and take
your IDE out of the equation.

However, when I try to run the jar after that, I get
NoClassDefFoundError's when it comes time to instantiate a class
that's in one of the "inner" jars.

Jar's cannot have 'inner jars'.

You must unpack all the classes and repackage
them as a single jar for you to be able to
call resources back out.

Either that or package them as Jar and have
your app. extract the jar's back out at first
run to the user.home or similar..

Is there a way to get Eclipse to magically ...

Eclipse's 'Magic' stopped for me when it suffered
a fatal freeze and locked me out of my dev
environment for as long as it took for me to decide
to toss it and use the command line and a simple
'keyword highlight' editor..

[ F'Ups set to c.l.j.programmer ]

HTH

 

[Christophe Vanfleteren]

I'm writing a Java app in Eclipse. It uses some third-party jars,
which I have in my Eclipse workspace.

When I export my jar, Eclipse packs all of my class files AND all of
the jars I'm using into my exported jar. Okay... great.

However, when I try to run the jar after that, I get
NoClassDefFoundError's when it comes time to instantiate a class
that's in one of the "inner" jars.

I guess I could distribute the third-party jars separately, but then I
need to provide the user with a way to set the classpath when they run
the app (which means platform-independent "run" scripts). To get
around *that*, I guess I could unpack all of the jars into my compile
"bin/" directory with the rest of *my* stuff, but then that gets stuff
all mixed up.

Is there a way to get Eclipse to magically package a single jar which
would set the classpath to point to the jars *within* my jar (or is
that even possible with the Sun J2RE)?

Jars within jars are not possible with default classloaders, and would be
very inefficient to implement anyway.

If not, what's the best way that people have found to get past this
problem?

Thanks,
- Joe

Look at the Class-Path attribute of the MANIFEST.MF file. You'll have to add
those 3rd party jars to it in your main, runnable jar.

 

[Christophe Vanfleteren]

Eclipse's 'Magic' stopped for me when it suffered
a fatal freeze and locked me out of my dev
environment for as long as it took for me to decide
to toss it and use the command line and a simple
'keyword highlight' editor..

It's a shame that you let one bad experience ruin the whole deal. I find
myself a lot more productive using an IDE. I don't see how I could go
without autocompletion anymore.

Just one example: recently, I had to work with the Amazon webservice. After
I generated the required classes from the WSDL using Castor, there where
about 60 of them. Add n methods to each class. Now imagine yourself
constantly looking at the generated Javadocs to find what you need vs using
an IDE with autocompletion. I wasn't going to use all my time memorising
those classes when I knew I'd only need to use them one time anyway.

I know it doesn't matter that much when using core JDK classes, because you
know them anyway, but when having to use an entire new API, nothing can
beat the IDE features like autocompletion, inline Javadoc and code
browsing.

 

[Andrew Thompson]

It's a shame that you let one bad experience ruin the whole deal.

(ehh.. shrugs) I've really just been too
slack to invest the start-up time in a new
IDE. I think I'll try a different flavor
to Eclipse next time round though.

I suppose I should get over my little
gripe and stop bad-mouthing a free
(and powerful) IDE.

"If you don't like it, demand a refund" ;-)

 

[Christophe Vanfleteren]

(ehh.. shrugs) I've really just been too
slack to invest the start-up time in a new
IDE. I think I'll try a different flavor
to Eclipse next time round though.

I suppose I should get over my little
gripe and stop bad-mouthing a free
(and powerful) IDE.

"If you don't like it, demand a refund" ;-)

You might want to consider Netbeans. I've been using it for years and I've
never been locked out of a project before, so that should be a big plus

The windowing system and the L&F has also improved a lot since 3.6.

 

[Stefan Waldmann]

On 23 Apr 2004 03:07:01 -0700, Joe Emenaker wrote:
[snip]
You must unpack all the classes and repackage
them as a single jar for you to be able to
call resources back out.
[snip]

Hi,

there are some cases where that doesn't work. For example when you have
an app that sends e-mails using mail.jar and activation.jar. If you mix
both in one single jar, your app won't work correctly any more, i.e. the
sending of mails will fail.

 

[Andrew Thompson]

You must unpack all the classes and repackage
them as a single jar for you to be able to
call resources back out.
[snip]

Hi,

there are some cases where that doesn't work. For example when you have
an app that sends e-mails using mail.jar and activation.jar. If you mix
both in one single jar, your app won't work correctly any more, i.e. the
sending of mails will fail.

Fail how?
Do the fully qualified classnames clash?

Do they work if you dump both jar files
(complete) into the final distribution jar?

More details, please.