ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <dona...@apache.org>
Subject RE: Did somebody say Shut up and Write? :)
Date Tue, 02 Jan 2001 23:43:03 GMT
At 02:32  21/12/00 -0800, Jose  Alberto Fernandez wrote:
>Here is my vision:
>
>ANT 2.0 I see as several collaborationg parts that when assemble together
>produce a very good OS independent build tool. These parts however, and
>maybe only to some extend are loosely coupled to one another, via APIs and
>interfaces. These parts are:

agreed.

>1) Execution engine.

yep. Of at least 2 levels - a task execution engine and a project execution
engine. These are separated so that other projects can reuse the task
execution engine.

>3) XML Language.
or a tree structured data-source ;) We already only want to deal with a
subset of valid XML (ie can only have text or element but not mixed
content) and I can quite easily see other sources of taskdata. (embedded
directly into .class file for instalshield app, from ldap/database for
cron/job engine, from an xslt processor for stylebook engine etc.

>4) User interfaces.
I prefer the term AntEater uses (namely FrontEnd) as it is a more useful
description I think ;)

>1) Execution engine
>-------------------
>
>Certaintly the basic functionality of ANT is its ability to execute
>tasks and to follow and resolve dependencies. Whether we consider
>projects as especialized tasks, or just targets as specialized tasks,
>is not too relevant in principle. I would advocate however for having an
>engine that knows as little as possible about tasks as we can do.

+1

>Another aspect I consider part of the engine is its ability of 
>creating an internal representation (what we call today a project) out
>of some XML "inspired" source format. No user, nor other of the loosely
>defined components should need to know, nor rely on the engine internal
>representation.

agreed.

>Differences with ANT 1.x:
>-------------------------
>
>- In ANT 1.x the engine, knows about certain tasks that have particular
>priviledges, like being allowed outside <target>s. This makes very difficult
>to extend the model or modified in the future.

Right - I am not sure how to deal with this. Ages ago when no tasks were
allowed outside targets public outcry ensued ;) The main reason was that it
required a magic target and extra dependencies (to setup taskdefs/properties).
It may also become more difficult if we move to AntFarms notion of import
(thou we could fix it with addition of "magic" on_import targets ...). Not
sure what do you think ?

>- I believe the current <script> capabilities of ANT 1.x are misguided since
>it allows direct manipulation of the internal representation of the engine.
>This means that users have access and knowledge of the internal
>representation of the projects, whch makes very difficult the evolution
>of the engine in the future. I would argue that ANT 2.0 should not allow
>or discurage such manipulations.

I am beginning to agree with this now.

>- I do not think that the GUI nor any other tool should have tight bound
>access to the internal representation. Nor the internal representation
>should be slanted to support this or that GUI approach. A Java IDE may know
>about packages and classes, but it certaintly does not allow users access to
>the class file internal representation. An IDE may have the ability to
>manipulate the syntactic tree of the language it is specialized for, but do
>not manipulate the compiled code produced out of the syntactic elements.

I partly disagree. I don't think allowing access by frontends should be
banned but requiring access via any non-trivial means (ie w3c DOM) is
definetly a no-no ;)
>
>2) Tasks
>--------
>
>Tasks are what make ANT, ANT. This is the most important contribution of ANT
>and where users investmentments may be most affected when changes happened.
>I would argue that ANT 2.0 should keep as much as possible the same
>definition of Task as in ANT 1.x. ANTs Task API should be the most solid
>and stable part of ANT.

agreed.

>ANT 2.0 should provide a well balanced predefined set of Tasks providing all
>the basic functionality required for building complex Java based projects
>which may require the execution of applications beyond what is offered as
>part of the JDK.

agreed.

>ANT 2.0 sould provide the ability to add new sets of tasks, packaged
>together as well as the ability to declare individual tasks.

and again ;)

>Differences with ANT 1.x:
>-------------------------
>
>- We need to define a good set of CORE tasks to be shipped with ANT which
>are stable and whose stability is promissed to be maintained. This as
>opposed to the curret kitchen-sink approach of having all kinds of tasks
>shipped and
>maintained by Jakarta-ANT.

right. Candidates include packages concerning files, core (ie
properties/taskedef/import/datadef etc), jdk-tools, text-tools
(replace/fixcrlf/patch etc), util-tools (zip/timestamp etc), net
(telnet/ftp/mail/etc) etc. Notice that in most cases they model the package
hierarchy that java uses. 

>- Provide a way to declare and used prepackage Task sets, which Jakarta-ANT
>or some other group may define for some set of common build process: EJB
>deployment, for example. 

right - interface/impl setup.

>3) XML Language:
>---------------
>
>On the user front-end ANT builds are represented as XML. The source or
>any preprocessing of the XML (XSLT, CSS, etc) is irrelevant with respect to
>the ANT engine is concerned. 

right.

>4)User interfaces
>-----------------
>
>ANT 2.0 should provide a CLI interface as will as other interfaces GUI that
>can be developed independently. Nor the CLI interface nor other tools
>should have a priviledge access to ANT internals. They all should be at the
>same level to validate that we are providing the correct functionality.
>
>ANT should be user interface agnostic. Concepts like Workspace, and so on,
>in my opinion relate to the user-experience and GUI usability, they belong
>on the GUI tool but not on ANT. User-configuration (CSS, for example) may be
>associated to a project by a GUI thru the definition of a workspace, but it
>should not be a concept manipulated by ANT.

I now agree - thou it would be nice to have the concept of top-level
workspace that set "environment/context variables" as in JDDs latest
proposal. However I think that this belongs to convention and shouldn't be
mandated by the tool - maybe another tool thats over the top can mandate
this structure but I don't think base ant should. Which is why I still
prefer the AntFarm approach ;)


Cheers,

Pete

*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof."                   |
|              - John Kenneth Galbraith               |
*-----------------------------------------------------*


Mime
View raw message