Mailing-List: contact ant-dev-help@jakarta.apache.org; run by ezmlm
From: "Conor MacNeill" <conor@m64.com>
To: <ant-dev@jakarta.apache.org>
Subject: RE: [PROPOSAL] jar distribution system
Date: Fri, 1 Dec 2000 00:56:48 +1100
Message-ID: <003401c05ad5$620da850$80dc1fcb@cognet.com.au>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Importance: Normal
In-Reply-To: <m3zoih7n4n.fsf@bodewig.bost.de>

> From: Stefan Bodewig [mailto:bodewig@apache.org]
> Sent: Thursday, 30 November 2000 21:47
> To: ant-dev@jakarta.apache.org
> Subject: Re: [PROPOSAL] jar distribution system
>
>
> Jon Stevens <jon@latchkey.com> wrote:
>
> > I have placed the start of cjan.xml up on the jakarta.apache.org
> > site
> >
> > <http://jakarta.apache.org/cjan/cjan.xml>
> >
>
> Just a quick thought:
>
> CJAN (the client side application) needs some way to know whether a
> given dependency is fulfilled on the local system or not. I see two
> options here:
>
> (1) keep track on all JARs that have ever been loaded and installed in
> a CJAN registry.
>
> This forces the user to install every component which might be
> available to CJAN through CJAN - I don't think you can expect this on
> a multi user system, even for single use boxes this seems too strong
> therefore I'd prefer
>

I wonder how extensive this cjan system might be. Should it be a system
for simply downloading the support jars needed for a particular product.
That doesn't really manage the problem, though. Where does it put these
jars? How does it "connect" the product in question to the jars. Can
this be standardized or is it the user's responsibility?

If I think beyond simply downloading the support jars to some form of
package/product management, I think it needs to become more "invasive".
Consider the problem of trying to have Tomcat 4.0 and Ant on a system
(This is just an example). One requires Jaxp 1.0 and the other Jaxp 1.1.
(I have run into some problems using ant with Jaxp1.1 - sealing
exception - whatever that is). The approach to this sort of problem
today is to have a whole load of *HOME environment variables which
"locate" the approriate jars. The build scripts then copy the
approrpiate jars into the lib area where the product's launcher script
dynamically builds the appropriate classpath.

A simplistic approach would be to standardize this system of lib
directories across products and have cjan copy the necessary support
jars into the product's lib directory. A central repository on the local
system of product jars would need to be used, I guess.

Such a simplistic approach seems rather poor, however. Why duplicate
support jars in each product's lib directory? I can concieve of a cjan
product-launcher which would manage a product's classpath. Some form of
classloader which dynamically constructs the classpath using the
installed jars that satisfy the correct product dependencies, and then
launches the Main class? Is that going to be feasible?

I don't think the "available" approach is going to work. It relies on
the classes being in the classpath, but version conflict is one of the
problems cjan seeks to address. I think it is going to need a repository
in which it tracks information about what products and (potentially
conflicting) versions have been installed.

I have some questions which I think it may be interesting to think
about.

1. To what type of user is cjan aimed? Is it a) the CVS developer, b)
the source distribution user, c) the binary distribution user or some
combination of these. I think it make a difference in terms of what we
want cjan to do and what we include in distributions?

2. How pervasive/invasive should cjan become? Can it be a requirement
for a product to launch?

3. What are the goals - simple automated downloads of support jars for a
single product - no attempt to worry about managing the mismatch of
versions across a system. Or should it be a package management system
which reports, or even tries to resolve, version conflicts?

Maybe I am "overthinking" the whole issue - thoughts?

Conor