On 10/05/2010 8:27 AM, Stefan Bodewig wrote:
you won't like what I'm going to say 8-)
Oh man, it is never easy, is it?
The following non-deprecated tasks use copyFile or copyResource as well:
<move>, the WebLogic deployment tool,<netrexxc>,<rmic>.<concat> and
<echo>.
For most of them I'd be willing to accept the backwards incompatibility
and just have the tasks throw exceptions if they cannot write to the
destination files. The main exception to me would be<move> and
<concat>.
I agree. These are the ones we need to be cautious about. Possibly echo
could be an issue as well, but is less of a concern I think, so long as
it gets a force flag (or equivalent).
<move> will try to perform a rename which falls back to delete if
File#rename fails - so in general it will replace read-only files. To
be consitent it should either check whether the destination is read-only
before trying to rename as well, or it should always overwrite existing
files in copy mode. I tend to perform the check before renaming and am
not sure what the default should be.
I think the check before renaming makes sense.
As for the default, I'm still torn. I think that our current behaviour
is just a bit obnoxious: I don't care how you've marked permissions on
your files, I'm going to do what I want. But thinking of all the builds
that might be blithely relying on that behaviour is a bit scary. So
again, leaning toward force=false
<concat> already defines an attribute named force - and it does just
what the attibute named overwrite does for<copy>. Does anybody have a
good idea for an attribute name that says "overwrite read-only
destination files" and can be used in both<copy> and<concat>?
What a pain. But given enough time we can fix this:
1) On Concat, add an overwrite attribute and mark the force
attribute as deprecated with a warning
2) Add force to copy, echo, etc
3) add forceReadOnly to Concat
Eventually we can get to the point where we remove force crom Concat
altogether for a release or two, and then reintroduce it.
Is it worth the effort to get this consistency, or have I slipped into
the land of Hobgoblins for little minds?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org
