You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by Sam Ruby <ru...@us.ibm.com> on 2001/01/02 13:41:23 UTC

Re: build.classpath and tinderbox builds

Peter Donald wrote:
>
>> If I don't hear anything shortly, I will check in
>> the change with having the system class path before
>> the build's class path being the default.  If
>> anyone objects after that point, changing the defaut
>> is easy enough...
>
> I'm -1 because it breaks backwards compatability.
> While I think it is a good idea I really don't want
> to go through and change all my build files/environment
> again ;) Wait till Ant2.0 before breaking backwards
> compatability please ;)

While I will respect your -1, I want to understand first.

First, I presume your objection is to changing the default, not to the
build.sysclasspath property overall?

Second, I would like you to verify that including the classpath in your
environment in addition to the classpath specified in the build.xml would
break your builds.

Third, there really is no need to change all your build files...one line in
${user.home}/.ant.properties would suffice.

- Sam Ruby

P.S.  The current implementation leads to anomolies whereby the available
task and the javac task could see different things.  I'm planning on moving
this classpath merging code into tools/ant/util and updating a number of
tasks to use this common function.


Re: build.classpath and tinderbox builds

Posted by Peter Donald <do...@apache.org>.
At 07:41  2/1/01 -0500, Sam Ruby wrote:
>> I'm -1 because it breaks backwards compatability.
>> While I think it is a good idea I really don't want
>> to go through and change all my build files/environment
>> again ;) Wait till Ant2.0 before breaking backwards
>> compatability please ;)
>
>While I will respect your -1, I want to understand first.

;)

>First, I presume your objection is to changing the default, not to the
>build.sysclasspath property overall?

right.

>Second, I would like you to verify that including the classpath in your
>environment in addition to the classpath specified in the build.xml would
>break your builds.

for some of them yes. Mainly as you may have noticed I am a strong
proponent of versioned binaries ;) As such a lot of the projects I have set
up rely on the versioned binaries rather than any that may or may not be on
classpath. Worse some developers environments will have their classpath
setup to develope with version 2.x of a project while the other projects
they build rely on 1.x. It is simple to fix on my part - namely a line "set
CLASSPATH=" in all the build.[sh|bat] files.

>Third, there really is no need to change all your build files...one line in
>${user.home}/.ant.properties would suffice.

The only problem I have is that it is not backwards compatable. We decided
that the next version was to be fully bacwards compatable with only
bug-fixes ... thou maybe we could classify this as a bug fix as it does
make more sense ;)

If we agree that backwards compatability for this is not an issue then
consider this a +0 otherwise the -1 stands ;) Either way I am fine with it.


Cheers,

Pete

*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof."                   |
|              - John Kenneth Galbraith               |
*-----------------------------------------------------*