Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #38880 > unrolled thread

Preferred way to distribute application

Back to article view | Back to comp.lang.java.programmer

Contents

  Preferred way to distribute application Graeme Geldenhuys <graemeg@example.net> - 2019-04-08 12:28 +0100
    Re: Preferred way to distribute application Joerg Meier <joergmmeier@arcor.de> - 2019-04-08 14:46 +0200
      Re: Preferred way to distribute application Graeme Geldenhuys <graemeg@example.net> - 2019-04-10 10:29 +0100
    Re: Preferred way to distribute application Patrick Roemer <sangamon@netcologne.de> - 2019-04-10 16:22 +0200

#38880 — Preferred way to distribute application

What is the preferred way to distribute a console java application?

For example:

  1.  Package everything into a single JAR with embedded jar
      dependencies.

  2.  Package application into a single JAR but don't embed any
      dependency jars. Have the dependency jars as a separate
      downloadable archive.

  3.  Package everything into a single JAR with related
      dependencies but dependencies are unpacked - seems to
      produce a slightly smaller final jar.


At the moment I don't have a lot of dependencies, but you never know
what the future of the project might dictate.

Not sure if it matters, but I'm using Eclipse to build the final JAR. In
the future I would like to let Maven do this for me so I can automate
builds.

Regards,
  Graeme

[toc] | [next] | [standalone]

#38882

On Mon, 8 Apr 2019 12:28:17 +0100, Graeme Geldenhuys wrote:

> What is the preferred way to distribute a console java application?

It depends on what you are distributing.

> For example:

>   1.  Package everything into a single JAR with embedded jar
>       dependencies.

This is by far the best default way if you want to distribute a runnable
application.

>   2.  Package application into a single JAR but don't embed any
>       dependency jars. Have the dependency jars as a separate
>       downloadable archive.

This is the best default way if you are planning on distributing a library
jar that others will include in their own, bigger projects.

>   3.  Package everything into a single JAR with related
>       dependencies but dependencies are unpacked - seems to
>       produce a slightly smaller final jar.

This isn't really good for anything. I don't think I would ever do that.

> At the moment I don't have a lot of dependencies, but you never know
> what the future of the project might dictate.

You pretty much SHOULD be using dependencies. One of Javas biggest
strengths is the huge, high quality ecosystem that allows you to not
reinvent wheels and instead focus on your unique sell points inspead of
spending a month writing the 2476283742th implementation of FileTools.java
or whatever else you can think of.

> Not sure if it matters, but I'm using Eclipse to build the final JAR. In
> the future I would like to let Maven do this for me so I can automate
> builds.

That is absolutely the right course. Maven is relatively trivial, and the
Eclipse IDE integration for Maven, m2e, is very good at making it seem
transparent when you use a Maven configuration from your IDE.

Liebe Gruesse,
		Joerg

-- 
Ich lese meine Emails nicht, replies to Email bleiben also leider
ungelesen.

[toc] | [prev] | [next] | [standalone]

#38889

Thanks for your time and feedback Joerg.

On 08/04/2019 13:46, Joerg Meier wrote:
>>   1.  Package everything into a single JAR with embedded jar
>>       dependencies.
> 
> This is by far the best default way if you want to distribute a runnable
> application.

This is what I was using up to now. Glad to hear I was on the right track.


>> At the moment I don't have a lot of dependencies, but you never know
>> what the future of the project might dictate.
> 
> You pretty much SHOULD be using dependencies. One of Javas biggest
> strengths is the huge, high quality ecosystem that allows you to not
> reinvent wheels and instead focus on your unique sell points inspead of

Coming from Object Pascal (Delphi/FPC) that is a rather large change for
me. The ecosystem in Object Pascal is really a drop in the ocean
compared to Java, and often I rolled-my-own solution in Object Pascal
projects. Indeed in Java it seems somebody has already written an
excellent library to reuse. I've quick discovered this when I wanted to
handle command line parameters, processing JSON files or producing PDF
output. Brilliant and well supported libraries already existed for all
of those. It saved me a huge amount of time.


Regards,
  Graeme

[toc] | [prev] | [next] | [standalone]

#38892

Responding to Graeme Geldenhuys:
> What is the preferred way to distribute a console java application?
> 
> For example:
> 
>   1.  Package everything into a single JAR with embedded jar
>       dependencies.

This requires some kind of Main wrapper for custom class loading, since
nested jars cannot be handled by the default class loader(s). At least
that was the status the last time I checked. Build tools that support
this option will automagically generate such a wrapper for you, and I
wouldn't expect any problems from these, but it does add some additional
complexity under the hood.

>   2.  Package application into a single JAR but don't embed any
>       dependency jars. Have the dependency jars as a separate
>       downloadable archive.

I certainly wouldn't recommend a separate download. However, you could
zip your jar together with the dependency jars and set up the proper
relative classpath in your jar's manifest. This is probably the most
brittle and pedestrian option, but it might work ok.

>   3.  Package everything into a single JAR with related
>       dependencies but dependencies are unpacked - seems to
>       produce a slightly smaller final jar.

That's probably the most common option. As long as you're not planning
to do the packaging manually (you shouldn't!), I don't think the choice
between 1 and 3 makes a huge difference.

If you're worried about jar size, there's tools like ProGuard that
specialize on this aspect.

> At the moment I don't have a lot of dependencies, but you never know
> what the future of the project might dictate.
> 
> Not sure if it matters, but I'm using Eclipse to build the final JAR. In
> the future I would like to let Maven do this for me so I can automate
> builds.

Just use whatever your build tool supports out-of-the-box. In the case
of Maven, that's probably the assembly plugin with jar-with-dependencies
settings, resulting in option 3 above. In the unlikely case of running
into name clashes in your dependencies, move on to the shade plugin.

Best regards,
Patrick

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.java.programmer

csiph-web