Re: [Fwd: Re: [Cp-tools-discuss] shape of the CVS]

[Nic Ferrier]

Julian Scheid <address@hidden> writes:


> In my opinion the cleanest way to package a Java app is to put 
> it into one jar file with an appropriate Manifest so that you 
> can do a  "java -jar /somewhere/someapp.jar". From my point of 
> view, putting stuff on the CLASSPATH is only useful if it's a 
> library and needs to be called from your application. 
>  
> I guess this approach does not work with free VMs yet (no good 
> jar file support at the time), but in the end its the cleanest way. 
> This way, you have application code and library code separated; 
> library code is easily accessible via CLASSPATH, application code 
> is separate stored in Jar files which are not on the classpath. 

Jar support is pretty good with free VMs, gcj supports it quite
happily, so do some of the other classpath variants.


But I don't agree it's that useful. The problem is when you have
hundreds of jar files which all interdepend on each other. The
manifest class-path attribute can not refer to dependancies within
the jar file, only outside of it, therefore you're back to the fixed
classpath or bulding a single jar file.


Consider Paperclips, the core lib is pretty free to boot the server
you need:

- gnugetopt, for command line handling
- gnusocketserv, for thread pooling/socket handling
- gnu-kawa, for dom and other bits
- gnu-jaxp, for sax implementation and other xml
- servlet.jar, for the API classes

Much of this is only concerned with the boot process and not with the
actual running server at all!


I used to provide a build target which unpacked all those jar files
and made one big one but as the dependancies have increased that
option has receeded into dissuse.

And paperclips is not that bad for dependancies! Consider other
servlet engines - a whole host of jar files is used.

In these circumstances the best thing to do is to have an "extdir"
(Sun provide one of these) or preferably an "extpath" which can be
used to pick up jars and automatically add them to the classpath
(that's what that little bit of script I refered to in my message
does).

If you have an extdir then the project maintainer can check whether
certain jars exist and what the version is, if no version exists the
project can install it and if a different version exists then the
project can depend on a specific  version.

This is exactly analagous to shared library support with languages
like C and C++.


Nic