ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Loughran" <>
Subject Re: Did somebody say Shut up and Write? :)
Date Thu, 21 Dec 2000 19:58:06 GMT

----- Original Message -----
From: "James Duncan Davidson" <>
To: <>
Sent: Wednesday, December 20, 2000 23:47
Subject: Re: Did somebody say Shut up and Write? :)

> The problem to be solved is cross platform building and packaging of Java
> based projects. That was the original goal -- and is still the clearest
> problem to be solved.

+1, with 'and deployment' insert in sentence 1.

> All other problems that can be solved are tangential to that original
> problem case. While it would be nice to use Ant to build c/c++ files --
> actually Configure/Make serve some really good needs here that just don't
> happen in the Java world. There's no reason why all of this can't be done
> with Ant as currently implemented even, however it's not the original
> problem domain. Same with XML/XSLT/Website builds. Possible, but it *is*
> important to know what the highest order bits are.


One of the great improvements of Ant over the build tools which I used
before was in the way it can be extended from within. If you wanted your
makefile to do something complex, you'd code it in the makefile to end up
with a makeful you were scared to look at, let alone share.

Ant, on the other hand positively encourages users to add their own
extension tasks, and then , once written, these tasks often submit the tasks
back to the ant CVS tree (for lack of a better place). This is where ant's
breadth of tasks has come from, especially all the deployment related tasks
from sql to the EJB suite.

Any split in ant future evolution runs the risk of impoverishing all the
alternatives, as some tasks would end up written for one ant descendant or
another, and the other ant variants would all be left the poorer. And I dont
want that to happen. It won't help my development process, and it won't
motivate me to submit new tasks or patches to any of the variants.

There are two possible solutions to this problem

Firstly, that we don't have a split in the Ant tree, that we do work to
resolve the issues, take the best ideas and design patterns from them all
and then produce something that is better than any one of its own. That
would be nice.

Secondly, that we come up with a means of allowing tasks to be re-used in
multiple frameworks. That would mean defining the task interface and base
implementation such that it wasn't dependent upon any particular framework,
and for all the common 'services' which the tasks use -from log() to setting
file times is provided via an interface which can by implemented by
different 'project service providers'.  If it is done right then someone
could build an installer application from ant tasks, or a GUI which executes
the tasks directly.

My ideal solution would be that we do come with a unified design, but that
the tasks evolve to become reusable beans of work which can be hosted inside
any task execution environment. That way if I want to do something in my own
code which talks to j2ee servers or imports SQL statements into a database,
I can do with these task beans and snippets of declarative XML, rather than
make life hard for myself by rewriting and re-debugging everything .

Of course the primarry purpose of the tasks should still be for the cross
platform java build tool called Ant.


PS, this morning's bootstrap is failing on my box with :-
C:\java\Apps\jakarta-ant\build.xml:288: Failed to copy
C:\java\Apps\build\ant\lib\core\jaxp.jar to
C:\java\Apps\jakarta-ant\lib\core\jaxp.jar due to
C:\java\Apps\jakarta-ant\lib\core\jaxp.jar (Access is denied) C:\java\Apps\jakarta-ant\lib\core\jaxp.jar
(Access is denied)

This is probably because I always check out from CVS read only by default,
and I can fix it with a quick attrib -r call, but a better solution would be

View raw message