ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Erik Engstrom" <Erik.Engst...@dot.state.mn.us>
Subject RE: [PROPOSAL] jar distribution system
Date Thu, 30 Nov 2000 21:43:43 GMT
Does any body know if Java Web Start has any thing to offer in solving this problem?

>>> Jose  Alberto Fernandez <JFernandez@viquity.com> 11/30/00 02:17PM >>>
Conor, these are good questions, however, as with ANT
I think we need to start with something, maybe not perfect,
maybe not covering every single aspect of the humongous
problem of software installation, but that at least
gives a starting point to the issues.

To answer some of your questions, I see the were to install
issue divided in two parts:

1) The specification of a product and its dependencies.
This is what these XML descriptions provide.
Here I think we may think on two types of dependencies:
a) Libraries, these are things that need to be available
and accessible during the execution of the product.

b) Other separate products reqired in the environment.
Fot example, TOMCAT "requires" ANT to be build, but not
as a library. If I do an exec of some application, I do not
need to have it installed as part of this one, I just need
to have it available in the system (in my executables PATH).

2) An ANT task that describes where to install dependent
products. It is in here where you would specify the location
in which libraries must be copied. As for (b) types, it may be
that the task will just warn you about the need to install them.
Mostly because their installation may require interaction.

Who knows, further along we may be able to display a dialog
indicating missing (b)s and asking if you want them downloaded
and installed. MAybe you can select wich one you want like from
a custom install and go from there. But to me, this is already
in the realm of GUI software installer. I think we could live
some manual activity, to start with.

Jose Alberto

> -----Original Message-----
> From: Conor MacNeill [mailto:conor@m64.com] 
> Sent: Thursday, November 30, 2000 5:57 AM
> To: ant-dev@jakarta.apache.org 
> Subject: RE: [PROPOSAL] jar distribution system
> 
> 
> > 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
> 
> 

Mime
View raw message