Even less valuable opinions inline :)
"Danny Angus" <[EMAIL PROTECTED]> wrote on 29/03/2002 10:08:45 PM:
> I don't know how this helps to clarify the situation, but I expect a
> "Jakarta registry" is probably required, and the ability for
sub-projects to
> define their classpaths as part of their installation procedure. In
which
> case a manifest reading ant task could ensure dependancies are satisfied
> without sub-projects having to bundle them.
See Maven's update-jars target.
> This raises a couple of issues though..
>
> a) it implies that there be an ant based installer for each application
> participating in the scheme
Maven creates an 'install-jar' as part of it's build process.
> b) it also implies that dependacy information and version
compatibilities
> can be written and read in a useful way
See the project descriptors for Gump & Maven.
> c) it may also require a seperate "jakarta_lib" to store common("shared"
not
> "popular") jars, to remove them from individual project directory trees.
lib.repo, as defined in maven's properties.
> d) smooth operation may also need a coherent jar version naming scheme,
and
> download directory structure to be adopted by all participating
> sub-projects, so that ant can find the ones it needs to download.
I wish.
> I think I'm going down the road of a kind of binary GUMP, where
dependancies
> are satisfied not by building from cvs, but by downloading binaries.
See maven's update-jars target.
> If I lose my job I know what to do..
I know I've mentioned maven a lot here lately, but after checking out
other stuff, and coming across it, it solves a ton of these problems, and
is being developed here as well.
The guys developing it are also open to feedback/criticism/junk.
--
dIon Gillard, Multitask Consulting
Work: http://www.multitask.com.au
Developers: http://adslgateway.multitask.com.au/developers
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
