suggestion on download distribution ...

[Giovanni Azua]

hi,

I am close to releasing an OS project (Maven multi-module project) and I
wonder what is best for the downloads section ...

- All delivered jar separately: users have to get the needed dependencies on
their own (is listed in the dependencies report)
- A tarball per project including cumulative dependencies e.g.
sub-module A (tarball including only jar A, documentation, maven
project etc)
sub-module B depends on A (tarball including jar A and B, all the rest
for both)
or
- A tarball per project with non cumulative dependencies e.g.
sub-module A (tarball including only jar A, documentation, maven
project etc)
sub-module B depends on A (tarball including only jar B,
documentation, maven project etc)

- Create bin and src distributions separately per project or just ship all
together?

IMO if I want to get an OS download I don't like to have to think what to
get but rather download the one or two choices not more. However with
multi-module projects it gets a bit hairy.

TIA,
regards,
Giovanni

 

[Tom Anderson]

I am close to releasing an OS project (Maven multi-module project) and I
wonder what is best for the downloads section ...

- All delivered jar separately: users have to get the needed dependencies on
their own (is listed in the dependencies report)
- A tarball per project including cumulative dependencies e.g.
sub-module A (tarball including only jar A, documentation, maven
project etc)
sub-module B depends on A (tarball including jar A and B, all the rest
for both)
or
- A tarball per project with non cumulative dependencies e.g.
sub-module A (tarball including only jar A, documentation, maven
project etc)
sub-module B depends on A (tarball including only jar B,
documentation, maven project etc)

I like the second option, with separate modules, and only the dependencies
of the module that are not also dependencies of the depended-on module
(!). Consider what happens when someone wants B and C, both of which
depend on A - having the humongo-packages will make them download A twice.

Note - don't pack all the depended-on code into the JARs with your code -
instead, supply separate JARs. I have a distribution of Xerces or
something which has another library (the XML APIs, i think) inside it, but
it's an old version, and it causes no end of configuration headaches.

- Create bin and src distributions separately per project or just ship all
together?

Separate, definitely. Many people have no interest in the source, so don't
make them take it.

IMO if I want to get an OS download I don't like to have to think what
to get but rather download the one or two choices not more.
Agreed.

However with multi-module projects it gets a bit hairy.

Also agreed!

tom

 

[Lew]

I like the second option, with separate modules, and only the dependencies
of the module that are not also dependencies of the depended-on module
(!). Consider what happens when someone wants B and C, both of which
depend on A - having the humongo-packages will make them download A twice..

Note - don't pack all the depended-on code into the JARs with your code -
instead, supply separate JARs. I have a distribution of Xerces or
something which has another library (the XML APIs, i think) inside it, but
it's an old version, and it causes no end of configuration headaches.

Make sure to list the dependencies in the 'Class-Path:' entry of the
JAR.

Have the tarball extract antecedent JARs into the same or
subdirectories of the location of the primary JAR. There should not
be "../" in the classpaths.

The scenario where B and C both depend on A, or to be more concrete,
where foo.jar and bar.jar both depend on log4j.jar, can be solved by
extracting all three into the same directory, and having your JARs
(foo and bar) list 'log4j.jar' in their manifests' 'Class-Path:'.
Obviously this is just one way, and really only suitable when B and C
are closely related anyway.

<http://java.sun.com/docs/books/tutorial/deployment/jar/downman.html>

 

[Giovanni Azua]

Hi Tom,

I like the second option, with separate modules, and only the dependencies
of the module that are not also dependencies of the depended-on module
(!). Consider what happens when someone wants B and C, both of which
depend on A - having the humongo-packages will make them download A twice.

Excellent! thanks, will do.

Separate, definitely. Many people have no interest in the source, so don't
make them take it.

Thanks, will do too.

Best regards,
Giovanni

 

[Giovanni Azua]

Hi Lew,

Make sure to list the dependencies in the 'Class-Path:' entry of the
JAR.

Yep just added it. It was sooo nicely easy:
http://maven.apache.org/shared/maven-archiver/examples/classpath.html

Have the tarball extract antecedent JARs into the same or
subdirectories of the location of the primary JAR. There should not
be "../" in the classpaths.

Thanks! will do.

<http://java.sun.com/docs/books/tutorial/deployment/jar/downman.html>

Thanks for the link, now having a look at jar signing

Best regards,
Giovanni