You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by Gus Heck <gu...@cognition.olin.edu> on 2003/05/21 23:06:15 UTC
Enhance chgrp/chown? (was: Re: cvs commit: ant/src/main/org/apache/tools/ant/taskdefs
Chmod.java ExecuteOn.java)
Stefan Bodewig wrote:
>
>>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
Re: Enhance chgrp/chown?
Posted by Stefan Bodewig <bo...@apache.org>.
On 23 May 2003, Stefan Bodewig <bo...@apache.org> wrote:
> On Thu, 22 May 2003, Gus Heck <gu...@cognition.olin.edu> wrote:
>
>> Have you found out anything about tandem/nonstop and chgrp chown
>> yet?
>
> No, sorry. I'll keep you posted.
OK, Tandem supports chown and chgrp, but at the same time,
Os.isFamily("unix") will be true for it so the special case isn't
needed (and not needed in Chown either where it is going to be removed
in a few minutes).
Stefan
Re: Enhance chgrp/chown?
Posted by Stefan Bodewig <bo...@apache.org>.
On Thu, 22 May 2003, Gus Heck <gu...@cognition.olin.edu> wrote:
> Stefan Bodewig wrote:
>> On Wed, 21 May 2003, Gus Heck <gu...@cognition.olin.edu>
>> wrote:
>>>Another logicical addition to all 3 of them might be allowing
>>>dirsets.
>> I think the type="dir" attribute covers this, doesn't it?
>
> I guess multiple ways of doing things just isn't popular with anyone
> around here.
Uhm, Perl used to be my favorite scripting language for quite some
time. But probably not because of TIMTOWTDI 8-)
If there is an existing way to do a thing I have no problem with
adding another way if it improves consistency accross tasks. But
there are not that many tasks supporting <dirset> (yet?).
> Makes me wonder why we have dirsets at all if we can't use them
> here, and only in a narrow way for subant...
The main reason for <dirset> has been as a nested element in <path>.
> I suppose type="dir" is a pre-dirset feature on chmod,
Yes.
> These tasks are not yet released, so maybe they should take DirSets
> instead?
They inherit it from ExecuteOn, so they cannot un-use the attribute
(well, they could override the setter and throw an exception).
> Maybe fileset should have had a type="dir|file|both" instead of
> having Dirsets.
<fileset> always does the implict type="both" - it is the task that
decides whether it invokes getIncludedFiles or
getIncludedDirectories. Take a look at the code of FileSet and
DirSet, they are identical.
We considered making dirsets and filesets interchangeable by having
dirset return the included directories in getIncludedFiles but decided
against it - not just because it was hackish but also because tasks
might rely on the fact that getIncludedFiles returns files and not
directories.
> What direction should I be taking with chgrp/chown here?
Thinking about it a second time - add <dirset> support to ExecuteOn.
> Given the constraints of back compatability, it seems that the only
> way to make life easy for the user is keep adding the new ways of
> referencing things (ie dirsets) to the old tasks in which they make
> sense.
True.
> ok I understand. Have you found out anything about tandem/nonstop
> and chgrp chown yet?
No, sorry. I'll keep you posted.
Stefan
Re: Enhance chgrp/chown?
Posted by Gus Heck <gu...@cognition.olin.edu>.
Stefan Bodewig wrote:
> On Wed, 21 May 2003, Gus Heck <gu...@cognition.olin.edu> wrote:
>
>>Stefan Bodewig wrote:
>>
>>>>currently chmod has a fair number of additional features.
>>>
>>>Which are?
>>>
>>
>>dir, includes, excludes, defaultexcludes...
>
>
> Please don't! These attributes come from the pre-fileset time and are
> only kept for backwards compatibility. Please look at the special
> case in Chmod's execute that is needed to keep the old behavior of the
> dir attribute.
>
>
Ah glad I asked.
>>Another logicical addition to all 3 of them might be allowing
>>dirsets.
>
>
> I think the type="dir" attribute covers this, doesn't it?
>
I guess multiple ways of doing things just isn't popular with anyone
around here. Makes me wonder why we have dirsets at all if we can't use
them here, and only in a narrow way for subant...
I suppose type="dir" is a pre-dirset feature on chmod, which I may have
inadvertently propogated to my tasks because dirset was very new at the
time I wrote them. (which was 4-5 months before they were commited due
to the 1.5 release feature freezes). These tasks are not yet released,
so maybe they should take DirSets instead?
Granted that one would then need to supply a dirset and a fileset to get
the "both" effect, but it would seem more consistant with the
documentation of fileset which entirely fails to mention that
directories are matched too. (unless you count the fact that /CVS is one
of the default excludes).
So what is the purpose of DirSet? Maybe fileset should have had a
type="dir|file|both" instead of having Dirsets. (of course with dirset
released, it cant' be undone)
What direction should I be taking with chgrp/chown here?
Thinking out loud... It looks like we are not winding up with one way of
doing things, but several ways that cannot be mixed between tasks. This
will force the user to remember which flavor of file or directory
specification a particular task finds tasty.
To put it another way, I think we want to make using ant as simple as
possible. To me life is simplest when any logical answer will do, and
failing that, simple if there is one answer that always works. The worst
case is a hashtable of case specific answers. The hashtable is what we
are in danger of here.
Given the constraints of back compatability, it seems that the only way
to make life easy for the user is keep adding the new ways of
referencing things (ie dirsets) to the old tasks in which they make
sense. (much like has been done to chmod with filesets). This way at
least, A dirset would always work and older ways you might or might not.
If my logic is correct, and the goal is to minimize the number of ways
to acomplish the same thing, we should not release chgrp and chown with
the old method (type=) but rather convert them to a DirSet accepting
version. (and add dirsets to chmod). This change would break builds
(like mine particularly), but hey it is an alpha version... such is life.
The pruning of things like chmod's dir atribute can be part of ant 2.0
where back compatability is not one of our promises... Of course if
dirset is prunable, then I have it all backwards :).
>
>>>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.
>
>
> To clarify. I don't think we should move any core task to optional at
> all - until we restructure our task system completely, which I'd
> expect to go along with antlibs, yes. There are more tasks than just
> chmod that are in core but don't really fit there (cvs for example).
>
ok I understand. Have you found out anything about tandem/nonstop and
chgrp chown yet?
-Gus
Re: Enhance chgrp/chown? (was: Re: cvs commit: ant/src/main/org/apache/tools/ant/taskdefs Chmod.java ExecuteOn.java)
Posted by Stefan Bodewig <bo...@apache.org>.
On Wed, 21 May 2003, Gus Heck <gu...@cognition.olin.edu> wrote:
> Stefan Bodewig wrote:
>>
>>>currently chmod has a fair number of additional features.
>> Which are?
>>
>
> dir, includes, excludes, defaultexcludes...
Please don't! These attributes come from the pre-fileset time and are
only kept for backwards compatibility. Please look at the special
case in Chmod's execute that is needed to keep the old behavior of the
dir attribute.
> Another logicical addition to all 3 of them might be allowing
> dirsets.
I think the type="dir" attribute covers this, doesn't it?
>> 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.
To clarify. I don't think we should move any core task to optional at
all - until we restructure our task system completely, which I'd
expect to go along with antlibs, yes. There are more tasks than just
chmod that are in core but don't really fit there (cvs for example).
Stefan