Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > suggestion on download distribution ...

Reply
Thread Tools

suggestion on download distribution ...

 
 
Giovanni Azua
Guest
Posts: n/a
 
      02-18-2009
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


 
Reply With Quote
 
 
 
 
Tom Anderson
Guest
Posts: n/a
 
      02-19-2009
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.
 
Reply With Quote
 
 
 
 
Lew
Guest
Posts: n/a
 
      02-19-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)

>


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


 
Reply With Quote
 
Giovanni Azua
Guest
Posts: n/a
 
      02-19-2009
Hi Tom,

"Tom Anderson" <(E-Mail Removed)> 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


 
Reply With Quote
 
Giovanni Azua
Guest
Posts: n/a
 
      02-19-2009
Hi Lew,

"Lew" <(E-Mail Removed)> 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


 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
PythonDSS: A suggestion for a book and accompanying software distribution Ajith Prasad Python 0 09-26-2004 12:53 PM



Advertisments