Mailing-List: contact ant-dev-help@jakarta.apache.org; run by ezmlm
Importance: Normal
Subject: Re: Jay's javac refactoring once again
To: ant-dev@jakarta.apache.org
Message-ID: <OF3B8037BF.CC4283F0-ON852569CF.005C62A8@raleigh.ibm.com>
From: "Sam Ruby" <rubys@us.ibm.com>
Date: Tue, 9 Jan 2001 12:11:56 -0500
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii

Stefan Bodewig wrote:
>
> Sam, when you talk about file batching and output
> parsing for jikes,

My concern there was long since determined to be invalid.  Ignore it.

> * Sam's tinderbox's needs and the addantruntime
> attribute cannot live together well.
>
> We have two very valid use cases: In the tinderbox
> case we don't want to trust the buildfile. The
> addantruntime is for situations where the buildfile
> writer doesn't want to trust the system CLASSPATH
> of the user.
>
> Say we have addantruntime="false" in our build file,
> what should we do? I'd say, unless build.sysclasspath
> has been set, the attribute wins - so
> concatSystemClasspath shouldn't be invoked. I'm not
> sure whether build.sysclasspath should win if it is
> set regardless of its value, but I tend to say yes.

I think that you are essentially on the right track.  There are a number of
sources which can influence the classpath, and we need to determine a clear
precendence rule for resolving these issues.  I'd probably start with the
classpath specified in the build file (if any), then optionally processing
the addantruntime attribute, and then finally the build.sysclasspath.  Note
that when build.sysclasspath is specified as either last or ignore, then
the value of the addantruntime attribute is very relevant.

I will say that as the use case which lead up to the need for the
addantruntime attribute argues for a default value of build.sysclasspath
being either last or ignore, then I no longer see sufficient justification
for the break in backwards compatibility and the default should be changed
back to ignore.

One suggestion I have is that instead of querying these environment
variables in several locations in the code, there should be a small number
of methods (currently one) in the Path class that does this in a consistent
manner.  If generalized, the name of the current method should be changed,
and perhaps there should be another overload added for the case where there
is the possiblity of the build definer specifying whether or not the
antruntime should be added, but all this logic should be in one place.

In short, I would argue that the method currently called
"concatSystemClasspath" should continue to always be called.

- Sam Ruby