currently chmod has a fair number of additional features.
Which are?
dir, includes, excludes, defaultexcludes...
chmod supports these with it's own internal fileset. I could duplicate it into my AbstractAccessTask (I think) to produce a similar effect in my tasks, but I hate duplicating code like that... it violates that whole DRY thing :).
Another logicical addition to all 3 of them might be allowing dirsets.
Finally, it seems a bit incongruous that chmod is not in optional/unix/ (now that that package exists),
It has been a "core task" of Ant virtually since Ant exists, so there is no way to move it from "core" to "optional" unless we restructure the set of built-in tasks completely IMHO.
Do you mean that if we move one thing there will be demand to move lots of others, or do you mean that there is a fundamental code level blockage to this that I have yet to perceive? Or is it a facet of the upcomming antlib thing?
Of course moving a task to another package, brings up back compatability questions at the api level
They can be solved by making the old class an (more or less) empty subclass of the new task. See Transform.java or SendEmail.java.
Ok, and if I do this, is there still a difficulty in moving the meat of the chmod class to where it can extend the same base as the others?
It doesn't seem like the sort of class that is likely to be extended or used in other code,
I disagree with "used". I could easily imagine using Chmod for a permission aware untar or unzip task for example.
Mmm yes I suppose that people might have done things like that with it.
So is worth my time to add the above mentioned features? (by that mean, would a reasonable implementation be likley to get committed?)
-Gus
