ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Thomas Haas" <>
Subject Re: Path & dir separators (was Re: Ant Principles)
Date Thu, 20 Apr 2000 20:45:07 GMT

> From: Kuiper, Arnout <>
> > From: Thomas Haas []
> [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?

(Note: path != directory)

Good question. I asked it myself and do not know. It depends on the problem
we want to solve.

I like your proposal:
To specify files or directories using task attribute, the File object way is
probably a good choice as platform specific build files always work
(whatever the platform is) and build files work cross platform on Unix and
Windows (Macs? anyone?), which are the most common platforms and
crossplatform requirements. If going that way, task designer should also
implement a nested file or directory definition for the more special cases.

The same aproach can be taken for pathes. The "popular ant" format maybe the
best choice as it can be used by most of the people right away (Unix,
Windows and both in mixed environments). All others have to use neted
elements - this is no loss, and not necessarly more typing. See below.

> 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

My concern were especially the mix of properties, which can hold almost
anything and static defintions, which can be well formatted. Beside taste
and convinience statical definitions are not an issue, as we can do whatever
we want (even absurd things like (foo)(file)(jar)).

> 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>

Actually it is not that bad, as createScrdir can return the object
implementing the "element" element of path. The example will become:
    <srcdir url=""/>
    <destdir file="../lib"/>

Which for sure is longer than  <copydir srcdir="../foo/" destdir="../bar/"/>
but still acceptable, if we go the purist way.
HOWEVER I have lost track of the creatXXX, setYYY and addZZZ discussion and
do not know if the example above is possible. Anyone?

The same can be done for pathes.

> 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;-)

I understand you very well and basicly have the same concerns. Path was a
solution to my problems in the JUnit task defining classpathes. The
community made it a concept, and I even start to like it :-) Probably a more
detailed proposal should be written. Is it up to me?

Defining command lines for generic processes is a very similar problem. A
commandline object similar to path exists. Anyone willing to discuss that
- tom

View raw message