ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rob Oxspring" <>
Subject Re: [VOTE] vote on general direction, details will be discussed later
Date Tue, 17 Apr 2001 19:35:57 GMT
----- Original Message -----
From: "Glenn McAllister" <>
To: <>
Sent: Tuesday, April 17, 2001 2:58 PM
Subject: Re: [VOTE] vote on general direction, details will be discussed

> > >> * better scripting/notification support so the hooks are available
> > >> * to send notifications at certain times.
> +0  I don't really care either way as long as implementing it doesn't
> require the core to do backflips.
> > >> * separate tasks into .tsk jars somehow. (Probably via function - ie
> > >>   java tasks, file tasks, ejb tasks).
> -0  We are going to have to break up the tasks into *some* sort of
> organizational structure, even if it only mimics the current ant.jar and
> optional.jar.
> > >> * Ask for a new CVS module for Ant tasks.
> -1 *untill* we get task loading implemented.
> > >> * It should be possible to modify details of the actual build
> > >> * (e.g. classpath, used compiler) without the need to change the
> > >> * build specification.
> If this means "don't use magic properties to affect the build", then I say
> +1.
> > >> * better subproject handling
> Conor has a point.  What does this mean?  If I've missed the discussion,
> I'm happy to catch up if someone will point me in the right direction.
> Untill then, -1.

When I mentioned this I couldn't find much on the list regarding
subprojects, so I brought this up.  I was expecting more discussion /
fleshing out of requirements before voting so I figureed something vague
would do.  The kind of things I was originally meaning are pretty much
covered by the following items (particularly the AntFarm stuff):

* make separate build files easy (ala AntFarm) and importing different
  projects a breeze

* create the concept of workspace so that projects can be built in a
  DAG and thus enable projects like catalina/tomcat to have an easy
  build process. It also helps CJAN to a lesser degree and would
  partially solve the JARs in CVS thing.

* support more control over the properties that are going to be passed
  to subprojects (modules)

Hopefully it would then be a breeze to add new subprojects without having to
change the master build files - just let the subproject define its own
dependancies and the parent would pick it up.

Peter Donald also added as clarification:
>Essentially it consists of possibly the following things
>* cross-buildfile dependencies
>* possibly cross-buildfile property access
>* sharing of "execution stack" (ie which tasks are already executed etc)
>* hierarchial scoping of properties (including const, overidable etc)

Maybe the general heading needs to be split down and voted on individually.
I would personally +1 each of the four points, although would hang back on
the property access to see how the scoping issue pans out.

> Glenn McAllister

Do You Yahoo!?
Get your free address at

View raw message