ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Twiggs, Glenn" <Glenn_Twi...@bmc.com>
Subject RE: Unbundling copying support files from the javac task
Date Tue, 07 Mar 2000 05:20:37 GMT
Conor (and Michael and James and Arnout...),

I think you've got me convinced. It is certainly good to reduce
"side-effect" processing, and optionality can lead to artificial complexity.
Heck, just last week I had the same discussion on an internal project where
I argued for verbosity over side-effects. Explicitly copying the
*.properties via

  <copydir src="src" dest="classes" includes="**/*.properties"/>

is looking better. Will this tag work as expected? I have not downloaded ANT
since all the include/exclude code was added.

Glenn.

> From: Conor MacNeill [mailto:conor@ebinteractive.com.au]
> Sent: Monday, March 06, 2000 4:23 PM
> To: ant-dev@jakarta.apache.org
> Subject: RE: Unbundling copying support files from the javac task
> 
> 
> Glenn,
> 
> The problem is that there tends to be other files that end up being copied
> across that you don't really want. For example, CVS can leave versions of
> files around when you do an update and there is a conflict., editors can
> leave backup files, etc. My view is that you should be explicit about what
> you want copied into the build area.
> 
> Of course, we could go for a backwards compatible attribute to control the
> behaviour
> 
> <javac copysupport="false" ...>
> 
> Each such option, however, adds to ant's complexity. It may be better to
> reduce optionality rather than increase it.
> 
> Conor

Mime
View raw message