ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Conor MacNeill" <>
Subject RE: [BUG?] Java Task adds Ant Classpath when forking
Date Wed, 10 Jan 2001 02:56:56 GMT

> -----Original Message-----
> From: Sam Ruby []
> Sent: Wednesday, 10 January 2001 2:40
> To:
> Cc:
> Subject: Re: [BUG?] Java Task adds Ant Classpath when forking
> [ copying Daniel as I'm not sure he follows Ant-dev, in any case,
> I haven't
> seem him recently here; Daniel the full text of Conor's reply is below ]
> Daniel, the change was identional, with the rationalle (and consensus with
> only Peter Donald essentially abstaining) that the previous behavior of
> ignoring the user's classpath was a bug.  Peter's concern was that this
> change was not backwards compatible, and the fact that this change has
> affected you to the point that you found it worth reporting as a potential
> bug certainly adds validity to this concern.  I would be very
> interested in
> your opinion after you have read this note.

I too have found this to break my builds. In my case, I can probably get
around it by setting my classpath appropriately. I'll give you my example,
albeit somewhat weblogic centric. I run a minimal classpath with just
weblogic/classes in it to supply the DTD for ejbjar (I actually want this
requirement to go away). When I run ejbjar, however, I place a weblogic
service pack jar in front of weblogic/classes. This is pretty important.
Ant's new behaviour means the weblogic/classes from my classpath ends up in
front. It also means that ant's parser is being used in place of weblogic's.
That is probably not a good thing.

In the light of this experience, I would like the default changed to ignore.


> Conor, as much as possible I would like tasks like <available> and <java>
> to interpret the classpath when specified in the same manner.  It seems
> much more error prone to expect each user of the class loader to act in a
> precisely similar manner than it is to embedd this logic inside of the
> class loader, but I recognize that opinions may vary.

I guess it is just about expectations and coupling. If I give a class loader
a classpath, I expect it to use this classpath and not tack on something to
the classpath. This seems like a side-effect to me. Such "higher-order"
behaviour belongs in the class loader users (available and java).

> In any case, adding
> the system class path in accordance to the value of the property is only a
> single method call, so the code bloat is managable.
> - Sam Ruby


View raw message