ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Duncan Davidson <>
Subject Re: Ant Principles
Date Wed, 19 Apr 2000 20:25:26 GMT
> I would like to have the possibility to load properties from a
> properties file that can be specified on the commandline.

Good point.

> I think it is a good idea to package each task in its own jar. To be
> able to quickly retrieve the actual needed task-class, these jars should
> be standardized somehow. Either with an entry in META-INF specifying the
> Task-class, or with a pattern like
> "".
> I prefer an entry in the manifest like
> "task:".

Yes, the manifest entry would be much better as defining a naming
pattern is really problematic when letting people write non apache

> I like the idea of having three places to define/store the taskdefs:
> in the Ant distribution (system-wide), in the users home directory
> (user-wide), and in a location specified by the project (project-wide).
> Taks should be resolved as follows:
> 1. Scan the directories mentioned in the <taskdefs extpath="foo:bar/ext"/>
>    path.
> 2. Scan the $user.dir/ant/taskdefs directory.
> 3. Scan the $install_dir/taskdefs directory.

Yes, that's the correct order when looking at it from that perspective.
Of course the implementation needs to cache, etc. But that's a detail.

> To prevent conflicts between two different tasks, which defines their own
> classes (with the same name), I propose to place each task in its own
> package. I think this is better than having only one class for each task,
> with lots of inner classes.

Right, of course we can only do this as a convention within our source
base. Others will just have to do it, but we can definitely spec that.

> If we are on a windows machine && the first character is a letter &&
> the second character is a ":" and the third character is a "/", then
> treat it as a full path. (This is the same as Duncan proposed, but
> I added a check on windows, and only allow the "/"). In some cases
> this might fail ("c:/foo" or "c" and "foo").

You're right. As soon as a concrete windows absolute path is spec'd,
it's pretty unique to windows, whereas a unix absolute path can be
translated relative to c:\. So the windows check is a useful addition to
the strategy. But I think that in that case, we need to allow '\' for
user friendliness. Of course we should have in all of our examples and
discussions the '/' :)

> Use the "//c/foo/bar" way, Scott proposed. I don't have that much
> problems with this strategy. It lets the users think about using
> full paths. Keep in mind that absolute paths should not be used,
> and this should be a rare situation then. This method has no
> ambiguities.

Given that absolute paths need to be firmly discouraged and are a user
convenience case, I think that allowing them the ability to spec what
they feel comfortable with is paramount. //c/foo/bar only makes since if
you've played around with cygwin.

> I like the latest proposal, with some minor modifications/additions:
> - Attributes are set with reflection "void setAttr(Type value)",
>   where attributes value are tried to be cast to the type Type
>   somehow. This can be done rather intelligent as Duncan pointed
>   out.


> - Nested elements are added with reflection. Look for a method
>   with the signature "void addObject(Type value)", where Object
>   is the name of the element. An object of type Type is instantiated,
>   and we recurse on that nested element. I think addFoo is better
>   than setFoo, because we can have multiple elements with the same tag.

Good point about using addXXX instead of setXXX due to multiple

>   To prevent conflicts with two tasks defining their own version of the
>   "Include" class, I propose to place each task in it's own package (See
>   before).

Also, if the tasks are scoped to separate jar files, the classloaders
will tend to resolve out conflicts. Additional benefit of using jar
files for each task.

> - All character data contained in the element other than other
>   elements is collected and reflected into the object via an
>   addText(String) method. We need addText, because multiple
>   text fragments can occur:
>   <copydir ...>bla bla
>     <include .../>bla bla
>     <include .../>bla bla
>   </copydir>
>   contains three textfragments "bla bla".

Yes, if it's important to reflect in in chunks. If instead we want to
just aggregate and reflect in in one chunk, then setText is appropriate.
This is still an open point in my opinion.


View raw message