newbie-question: make executable jar from eclipse-project

[Javier Vazquez]

How do I get an executable jar out of an eclipse-project?

I've read it should be possible using an Ant-script. Is there any other
possibility? What's this Ant-Thing about and does anyone know a good
introduction into this subject?

 

[Paul van Rossem]

How do I get an executable jar out of an eclipse-project?

I've read it should be possible using an Ant-script. Is there any other
possibility? What's this Ant-Thing about and does anyone know a good
introduction into this subject?

Just use menu File->Export...

Paul.

 

[Javier Vazquez]

Just use menu File->Export...

Let's say it's a JMF-Project, will the imported JMF-Libraries be
exported into the jar as well? I can't expect a normal user to have JMF
installed on his PC...

 

[Paul van Rossem]

Let's say it's a JMF-Project, will the imported JMF-Libraries be
exported into the jar as well? I can't expect a normal user to have JMF
installed on his PC...

If JMF is in a jar, you should install that together with your own jar
for the user.

There is some utility that you could use to put it all together into a
single jar (google for net.sf.fjep.fatjar). However I don't recommend
that. I don't know if it will work for JMF, I don't know if the JMF
licence allows it, and it doesn't improve the portability of your code.
Usually it 's more profitable to just deliver the required jars with
your own jar.

You said it yourself, you can't expect a normal user to have JMF
installed on his PC, so how can you expect him/her to have Java
installed on his/her PC? It's not that difficult to use an installer
that does it all for the user!

Paul.

 

[Oscar kind]

Let's say it's a JMF-Project, will the imported JMF-Libraries be
exported into the jar as well? I can't expect a normal user to have JMF
installed on his PC...

No. There are several ways to solve this:

1. Unpack the libraries and repack them in you .jar file.
This generally is a bad idea, because of several reasons:
- Licencing. Using a (L)GPL'ed library requires you to use the same
licence for your work. For commercial licences, note that this means
"reverse engineering", even though it's just unpacking, and is
generally prohibited.
- It's difficult to replace a library with a different version
(you doin't expect to need this though)

2. Use "Class-Path" headers in your manifest
This works fine, but requires you to distribute the libraries alongside
your application. They must be referenced from a location relative to
your application.

3. Require the user to have the libraries installed as extensions.
Apart from the fact that you stated you don't expect a user to do this,
it also means you're inviting version problems: all applications must
use the same version of the library. With option 2 the library version
to use can be managed per application.


IMHO, the second option to be the best.

 

[news t-online]

If JMF is in a jar, you should install that together with your own jar for
the user.

There is some utility that you could use to put it all together into a
single jar (google for net.sf.fjep.fatjar). However I don't recommend
that. I don't know if it will work for JMF, I don't know if the JMF
licence allows it, and it doesn't improve the portability of your code.
Usually it 's more profitable to just deliver the required jars with your
own jar.

You said it yourself, you can't expect a normal user to have JMF installed
on his PC, so how can you expect him/her to have Java installed on his/her
PC? It's not that difficult to use an installer that does it all for the
user!

Paul.

The Fat-Jar Eclipse-Plugin ( http://fjep.sourceforge.net/ ) also supports
the "One-Jar" option. With this option enabled, the referenced jars are
included as whole (no unzipping and rezipping). So there are no license
problems.

Best regards,

feri