> From: Thomas Haas [mailto:[EMAIL PROTECTED]
[Snip]
> Proposal:
>
> * Define pathes using nested elements (unless passed in as
> property).
> Elements are files (or directories) defined by the rules
> for files
Does this mean that paths cannot be passed as task attributes anymore?
[Snip]
What is the scope of your proposal? Does it only cover paths (sets of
directories/files) or does it also cover single files and single
directories? If it also covers the latter case, won't the task syntax
of some simple tasks become too lengthy?
Copying a directory will then become something like:
<copydir>
<srcdir>
<element file="../foo/"/>
</srcdir>
<destdir>
<element file="../bar/"/>
</destdir>
</copydir>
instead of
<copydir srcdir="../foo/" destdir="../bar/"/>
We can combine these two if the srcdir attribute is of type "Path", and
the Path class has a constructor accepting a String, which represents
some path-format (either the format of the local platform, the to bew
defined
X-platform Ant format or the "popular Ant" format). See some other postings
on reflection and nested elements.
Don't misunderstand me here, I like your path concept, but I'm trying
to find a balance between the number of characters I have to type, and
the flexibility;-)
Cheers,
Arnout
