«

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

On Wed, 18 Feb 2009, Giovanni Azua wrote:

> 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

--
All bloggers must die.

Giovanni Azua wrote:
>> 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)
>

Tom Anderson wrote:
> 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>

--
Lew

Hi Tom,

"Tom Anderson" <> wrote
> 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.

>> - 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.
>
Thanks, will do too.

Best regards,
Giovanni

Hi Lew,

"Lew" <> wrote
>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...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