ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Glenn McAllister <>
Subject Re: [VOTE] vote on general direction, details will be discussed later
Date Sun, 25 Mar 2001 21:10:44 GMT
Stefan Bodewig wrote:

> * The ability for GUI/IDE tools to integrate easily with object model
>   without reinventing the wheel and writing their own parser (which
>   antidote was forced to do).


> * support for numerous frontends - from command line over GUI to servlets


> * Fully interpreted at runtime. This almost requires some form of
>   abstraction/proxy that stands in place of tasks till it is
>   interpreted.  This can be hashtables/simple dom-like model/whatever


> * provide utility classes to aid in building tasks. ie like up-to-date
>   functionality abstracted

+1.  Good spot to think about the commons?

> * make ant-call a low cost operations so it can certain
>   optional/template-like operations

+1  It would be nice to use antcall without having to reload the entire build

> * allow facilities to build projects from multiple sources. ie CSS+xml
>   or XSLT+ XML or Velocity+text or database or from inside jars or normal
>   build.xmls etc.


> * move to a system that allows docs to be generated - doc snippets
>   should be included with the tasks they document.


> * allow tasks to be loaded from jars. tasks should be indicated by
>   either xml file in TSK-INF/taskdefs.xml or manifest file.


> * allow documentation to be stored in .tsk jars

Big +1

> * better scripting/notification support so the hooks are available to
>   send notifications at certain times.
>   Which hooks and where?

+1 with definition of which hooks and where.

> * separate tasks into .tsk jars somehow. (Probably via function - ie
>   java tasks, file tasks, ejb tasks).

+0.  Whatever way we pick to divy up the tasks into .tsk jars, we should stick to

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


> * provide support for user defined task configurations - i.e. give
>   users the ability to specify a default value for attributes (always
>   use debug="true" in <javac> unless something else has been
>   specified).


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


> * Ask for a new CVS module for Ant tasks.
>   We need to define rules for this to work - maybe the rules proposed
>   for the commons project could give us a start.

+1, but later on; preferably after we get the .tsk jar facility worked out.

> * It should be possible to modify details of the actual build (e.g. classpath,
>   used compiler) without the need to change the build specification.

Isn't this covered by "provide support for user defined task configurations?"
And what exactly is meant by "without the need to change the build
specification?"  Does it mean that you can change attribut values in a build file
*externally* from the file?

> * Task to prompt for user input.


> * Add cvs login feature.


> * Easier installation process. GUI - maybe webstart from the homepage.

+1 if this is in addtion to the current process

> * Logo for Ant.


> * detach Ant from System.err/.in/.out.


> * better subproject handling


> * build files should be declarative in nature

+1 if we could ever agree on exactly what "declarative" means. :-]


View raw message