ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simeon Fitch <meta...@yahoo.com>
Subject Re: [VOTE] vote on general direction, details will be discussed later
Date Thu, 22 Mar 2001 13:38:39 GMT

--- Stefan Bodewig <bodewig@apache.org> 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). 
> 
>   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.
> 

+1

> * support for numerous frontends - from command line over GUI to servlets
> 
>   corollary of the above?

+1 (although the goal should be restated as "support embedding via API",
just like you can link Java into a separate application).

> 
> * 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 (definately)

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

+1 (see org.apache.tools.ant.gui.acs.ACSFactory)

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

+0 (or "ant should be efficient with its resource usage????")

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

+0 (not knowledgeable enough)

> 
> * move to a system that allows docs to be generated - doc snippets
>   should be included with the tasks they document.
> 
>   Which DTD? Which tools for generation?

+0 (what does "move to a system" mean? Are we talking Doclet for Ant build
file?)

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

+1

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

-1 (requirement is too unclear; need to know what the impact of task
developers would be. What are the long term implications?)

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

+1 (same as above?)

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

+1 (and I add "make the semantics clearly and simply defined")

> 
> * 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). 
> 
>   Three ideas so far: a CSS like language, a <taskconfig> element,
>   properties following a specific naming scheme.

-0 (how does this affect the "simplicity" goal?)

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

+0 (I'd rather see this stated as "provide a consitent, scoped, proprities
model").

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

+0 (not enough knowledge to judge. Where does this diverge from the
existing CVS/Version Control task(s)).

> 
> * 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 (does this fall in with "allowing default values"?)

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

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

> 
> * Logo for Ant.

+0 

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

+1

> 
>   Beware of problems with spawned processes.
> 
> * better subproject handling
> 
>   Whatever that means in detail.

+1 (see above on "clear and simple semantics")

> 
> * build files should be declarative in nature
> 

+0 (feature or design goal?)




=====
Mustard Seed Software
http://www.mustardseedsoftware.com
mailto:simeon.fitch@mseedsoft.com
fax:1.309.424.4982

__________________________________________________
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail. 
http://personal.mail.yahoo.com/

Mime
View raw message