Mailing-List: contact ant-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: ant-dev@jakarta.apache.org
Message-ID: <3BCB6ED2.225919F7@progress.com>
Date: Mon, 15 Oct 2001 19:18:42 -0400
From: "Bill Burton" <billb@progress.com>
Organization: Progress Software Corporation
MIME-Version: 1.0
To: ant-dev@jakarta.apache.org
Subject: Re: Optional tasks
References: <HGEEIKOHHDJKIOMBLAAEKEBOEEAA.tneward@javageeks.com>
 <20011010121538.XURA13193.mss.rdc2.nsw.optushome.com.au@there>
 <003701c1519c$abc5a790$0100a8c0@jose>
 <20011011100200.FHIJ13193.mss.rdc2.nsw.optushome.com.au@there>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hello,

Peter Donald wrote:
> What they used to call Extensions are now called Optional Packages. They seem
> to like renaming stuff. I am not sure where you got that blurb from but the
> jdk1.3 stuff has it documented. Specifically I am looking at using stuff that
> places data in manifest like
> 
> Extensions-required: junit
> junit-Specification-Name: org.junit
> junit-Specification-Version: 3.7

AFAIK, that stuff only applies to applets or containers implementing JNLP
such as Java Web Start.  

> > > The type.lib.path can be extended by user the same way that the header
> > > (or library) serach path for gcc can be extended. Perhaps it could be as
> > > simple as
> > >
> > > ant -L ~/my/ant/lib/path

Yes.  Or it could be a path as below.

> > > However in reality you would usually define a OS environment variable to
> > > extend it. Probably something like
> > >
> > > export
> > > ANT_LIB_PATH=~/ant-ext/lib:/opt/some-local-tool:/usr/local/another/local/
> > >tool
> > >
> > > or whatever.

No.  Environment variables aren't needed!  A command line option or
property should be used instead:
    -L ~/ant-ext/lib:/opt/some-local-tool:/usr/local/another/local/

> > So we are just moving or incrementing the issue of managing the CLASSPATH
> > to also managing some other ANT_LIB_PATH. Not too much of an improvement.
> > My wish would be for ANT not requiring any special manipulation of
> > CLASSPATH nor any aditional environment variables.
> 
> Theres not much you can do about that. Didn't you punt it to the build file
> writer? Most people will ever have to deal with this because there will be
> reasonable default. I haven't come across a project yet where the reasonable
> defaults would not suffice.

Need to first think of Ant as a reusable container that can be
instantiated and configured within IDE's and other tools.  Then determine
a simple command line invocation strategy using a combination of command
line parameters and possibly a property file with sufficient information
to bootstrap the runtime.  Environment variables are of no use or help in
this scenario and only increase the complexity of scripts used to invoke
the runtime.  The only exceptions to this might be JAVA_HOME and ANT_HOME
which the wrapper scripts could continue to use.

At the bare minimum, all functionality currently in scripts to set or
modify the CLASSPATH needs to be moved into Java.  The end result is one
could invoke Ant with something as simple as:
    java -jar /usr/local/ant/lib/ant.jar -home /usr/local/ant -java_home
/usr/j2se
This would imply loading all jars in Ant's common/lib (like Tomcat) and
adding tools.jar to the classpath plus loading all tasks, etc. from Ant's
ext directory.  The path for the latter could be supplemented or
overridden with an -L option as described previously.

-Bill