ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kuiper, Arnout" <Arnout.Kui...@nl.origin-it.com>
Subject RE: Ant Principles
Date Wed, 19 Apr 2000 09:52:37 GMT
Hi,

I'm finally catching up. Here are some comments on the current
Ant principles:

Properties
==========

I don't really care how the properties are passed on the commandline,
as long as it can be done.

I can live with "ant foo=bar main", although it seems a bit unnatural
somehow. Personally I like having an option before it, like -p or -prop.

I would like to have the possibility to load properties from a
properties file that can be specified on the commandline.

Tasks
=====

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
"org.apache.tools.ant.taskdefs.copyfile.Copyfile".
I prefer an entry in the manifest like 
"task: org.apache.tools.ant.taskdefs.copyfile.Copyfile".

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.

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.

Filenames
=========

I like the idea of having "/" as a directory separator,
and ":" as a path separator. This makes Ant work more predictably
in a X-platform environment. As far as the windows community
is concerned, whenever you stop using relative paths, the build file
is not portable, even between windows machines which use different
drives. But in the rare case you _want_ to be unportable, we could
use either two strategies (in my opinion):

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").

or

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.

I like the second better.

Nested objects
==============

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.

  Suppose the argument type of setAttr() is String.
  1. Use it as is and we're done.

  Suppose the type is Foo.
  1. Check if Foo(String) exists. If so, use it, and we're done.
  2. Check if Foo(double) exists. If so, cast String to double,
     use it, and we're done.
  3. iterate step 2 for each primitive type.
  4. Failure...

  Suppose the type is a primitive type.
  1. Cast string to primitive type, and we're done.

- 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.
  In the following example, two include objects are added. If you named
  the method setInclude, you might expect that only the last include is
  known.

    <copydir src="${src.dir}" dest="${build.classes}">
      <include name="**/defaultManifest.mf" />
      <include name="**/*.properties" />
    </copydir>

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

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


My 3 cents,

  Arnout

Mime
View raw message