ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Conor MacNeill" <co...@cortexebusiness.com.au>
Subject Re: [VOTE] vote on general direction, details will be discussed later
Date Sun, 25 Mar 2001 07:25:42 GMT

----- Original Message -----
From: "Stefan Bodewig" <bodewig@apache.org>
To: <ant-dev@jakarta.apache.org>
Sent: Thursday, March 22, 2001 2:30 AM
Subject: [VOTE] vote on general direction, details will be discussed later


> A vote here should only indicate whether you agree with the goal
> itself, not with any of the suggested solutions (if there is one).
>
> * 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).

+1, but I am -1 on the solutions :-)

>
>   Two suggested solutions were allowing GUI developers to extend
>   object model (ie GUITask extends Task) or to have Task as interface
>   (ie GUITask implements Task). This way the GUI tasks could be W3C
>   DOM Elements, have property vetoers/listeners etc.
>
> * support for numerous frontends - from command line over GUI to servlets

+1

>
>   corollary of the above?
>
> * 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

+1

>
> * provide utility classes to aid in building tasks. ie like up-to-date
>   functionality abstracted
>
>   Need to become more specific here.

+1 - exec and execjava there already. Probably need zip/jar capability too.
Also move copy code out of project.

>
> * make ant-call a low cost operations so it can certain
>   optional/template-like operations
>
>   corollary of "fully interpreted at runtime"?

+1 in general but not sure what is meant by low-cost

>
> * 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.
>
>   allow the project tree to be built dynamically.

+1

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

+1

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

+1

> * allow documentation to be stored in .tsk jars

+1
>
>   corollary of the two points above?
>
> * better scripting/notification support so the hooks are available to
>   send notifications at certain times.
>
>   Which hooks and where?

Exactly. +1 in general but I would like to see specifics.

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

-1 - why? I'd probably go for core.task and then the various optional tasks
in categories, say ejb.tsk

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

+1

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

+1

>   Three ideas so far: a CSS like language, a <taskconfig> element,
>   properties following a specific naming scheme.
>
> * support more control over the properties that are going to be passed
>   to subprojects (modules)

+1

>
> * 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 - I think this can be done later. I'd like to get the task loading in
place first and then think about splitting.

> * It should be possible to modify details of the actual build (e.g.
classpath,
>   used compiler) without the need to change the build specification.
>
>   Do build.compiler and build.sysclasspath cover everything or do we
>   need to add more stuff like this?

-1 - Too vague for me. There is a lot of control already possible.
>
> * Task to prompt for user input.
>
>   Does affect core as we need a means to request input from the Frontend.

+1

>
> * Add cvs login feature.
>
>   Requires handling of user input.

+1 - can be done by manipulating the .cvspass file directly I believe.

>
> * Easier installation process. GUI - maybe webstart from the homepage.
>
>   This includes asking the user whether he wants to use optional tasks
>   and downloads the required libs. Automatic upgrades and so on.
>
>   Self-extracting jar installer: java -jar jakarta-ant-1.3-bin.jar.
>   Prompts for destination directory, extracts archive, fixes all
>   text files with fixCRLF task; on UNIX, makes scripts executable.
>   Could also modify ant scripts with the location of ANT_HOME.

+1 but I would add that installation without the instaler should remain
possible as it is today.


>
> * Logo for Ant.

+1

>
> * detach Ant from System.err/.in/.out.
>
>   Beware of problems with spawned processes.

+1

>
> * better subproject handling
>
>   Whatever that means in detail.

-1 without detail.

>
> * build files should be declarative in nature
>

+1 if we define declarative :-)



Mime
View raw message