ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From ru...@us.ibm.com
Subject Re: Ant Principles
Date Tue, 18 Apr 2000 02:38:02 GMT


First reactions:

.duncan wrote:
> ant projectfile.xml -props foo=bar;baz=bop [target]
>
>  Yes, I'd like to see the props defined this way.. This does reserve
> the ; and = chars, but I don't see a huge problem with this.

Semicolons on the command line are real annoying to Unix users...

I'd like to explore further the notion of eliminating properties entirely.
I'd like to see more rationale as to why they are necessary.

In HTML today, you can easily change all <h3> text to be blue through CSS.
The approach does not require passing properties around.

Also, imagine an addition to ant where you associate names with paths via
<directory> elements at the top of your project file.  Then we require all
tasks to reference paths by name.  I believe that the resulting build.xml
will be easier to understand and maintain.

The above are merely brainstorming.

> The current version of Ant allows the System property list to be
> consulted for a return value of the Project if the property requested
> doesn't exist in the Project property list. This can be considered to
> be confusion, and should not be carried forward.

+1 for removing System properties

> The other part that needs work is what happens inside the taskimpl
> areas. Right now reflection is used to set attributes on bean methods
> but it's heniously unclear how the best way to reflect the rest
> of the elements within the taskimpl tag should be performed.
>
> But, the tough part once again is reflecting this stuff in. We
> need a simple, clearly defined way (just like attribs are set
> using bean methods) that works the same way for every task. And
> just passing in a DOM fragment doesn't cut it as far as I'm
> concerned as I'd like to ensure that the XML impl doesn't
> get too close to the runtime impl and vice versa. It's a data
> format! :)

I don't follow this part.  What is currently defined for nested tasks (in
this case taskimpl?), then ProjectHelper looks for a createTaskimpl method
with no arguments that returns an Object.  That object could be anything -
an instance of a nested class, an existing object, anything. It could even
be the original object.  Once ProjectHelper has a handle on the object, it
is configured using reflection.  This process can nest infinitely.

> Sam, you're the scripting guy, not me, but something along these
> lines, along with a definition of the object model that is
> exposed to the scripting environment (project/target/task +
> properties) would be acceptable to me.

The core premise of my scripting work is that there shouldn't be a
difference between the data model exposed to Perl than the one exposed to
Java.  In many languages, I try to provide conveniences, like mapping bean
properties to object attributes, but this doesn't change the semantics of
the underlying data model.

>   <script>
>     <language="somelang">
>        if (bar) { set-property("foo", "bar") };
>     </language>
>   </script>

I realize that this is just an example, but I prefer <script
language="somelang">...

> Far far far too many people are inluding ant.jar with thier
> software. Do people include make? No. Do people include diff?
> No. So, we need to get Ant to the point where it's a first
> class citizen on the user's machine. This means an install
> and it means a directory structure.

+1.

> When ant starts, it scans the /ext dir, loads in all
> tasks and makes them available to the runtime. It doesn't
> do this by placing them on the classpath in the ant.sh
> script, but by using JAR class loaders.

The jar files that you will want loaded are likely to vary by project.
Look at the various build.sh/build.bat files around.  What is likely needed
is for the build.xml to define what jar files are needed by this project.

As hardcoding of jar paths inside of the build.xml is likely to cause more
problems, what would probably be better is for there to be a centralized
registry of projects.  Perhaps inside of the ant $install_dir someplace
should be a set of xml files which describe projects.  Each could simply
contain the path to a single jar file, and optionally the path to the
build.xml file used to build it.  Any given build could be run in a shallow
mode (only this project, assume dependencies are up to date), or deep.

> The tasktype directories contain the source code for the
> optional tasks, along with a project file to build them.
> When they are built, they should be placed into the
> /ext directory in a jar format...

Similar to above, I'd like tasks to be able to be placed wherever it makes
sense (imagine a word in a few years where many shrink-wrapped products
deliver their own taskdefs!).  Nor do I believe that all tasks themselves
need to be open source (I realize how sacrilegious this statement in this
context ;-) )  All that ant needs is a means to determine how to find the
jar, and optionally how to build it.

> In cases where the user must specify an absolute path on a
> windows machine that starts with a drive letter, it should look like
> 'C:/foo/bar'

+1 for an internal canonical representation.

-0.9944 for requiring users to be aware of it.  You and I write code
knowing that it will run on multiple platforms, so this would not be a
problem for us.  Users who only use Windows should not have to use a
"foreign" format merely because somebody else uses the same tool on another
platform.

Particularly as Java itself doesn't require this.

- Sam Ruby



Mime
View raw message