The two views of Ant's future direction (RE: Parameterized "task-function")

[Diane Holt <ho...@yahoo.com>]

In reading through all the mail regarding "Ant is/should-be a scripting
language" vs. "No it's not and never was and never will be", I've been
wondering if there's any room for compromise. I'm wondering if we could
have the true-to-the-nonscripting-purists' vision of Ant as Basic Ant,
then have the scripting-capabilities as extensions to that. Would it need
another name? I don't know (but 'extant' comes to mind). Would it need to
be a separate project? I don't know (clearly, 'extant' would be dependent
on 'ant'). Should Ant2 allow for the possibility of being extended to
include the types of tasks such as <if>, <for>, <case>? I think so.

I've finally had a chance to look at the examples Roger Vaughn posted that
use XSLT (and I really do appreciate your having done that, Roger -- thank
you) -- and I can now say, I have to agree with those people who have said
yuck to using it. I know I said I prefer having a separate
"task-definitions" (or "templates", "rules", whatever) file, so that the
build-files themselves could potentially be simplified, but, now that I've
had a chance to see how the XSLT/XML stuff would be put together, I have
to say that's not what I had in mind. What I'd actually prefer is to have
the task-definitions file(s) be in XML, and the build-files be plain text
-- but I don't expect to actually have that happen, since it would mean
writing a parser for the plain-text files. As a compromise, I'd be willing
to see the majority of the complicated XML stuff in definition file(s),
and only the minimum amount of XML in the build-files. And it seems to me
that the only really workable way to even have that happen is to allow
(for those of us who even want/need to use Ant that way, since not
everyone would) for the types of "scripting" capabilities that Jason,
James, and yes, myself (and others) have asked for. For simple projects,
basic Ant would be all that would be needed -- but for large, complex
build systems, Extended Ant could be used.

Would this approach work? I don't know -- but it sure seems like the
current Is-so/Is-not approach isn't really getting us anywhere useful.

Diane 

=====
(holtdl@yahoo.com)



__________________________________________________
Do You Yahoo!?
Yahoo! Photos - Share your holiday photos online!
http://photos.yahoo.com/

Re: Query -- status of 'current' ant...

[Peter Donald <do...@apache.org>]

At 02:11  15/1/01 -0600, Ken Wood wrote:
>How is the current CVS version of ant? Is it
>stable? 

I would grab a version of about a week or maybe two weeks ago. A few
largish changes occurs (change of behaviour of build.sysclasspath and
change of java into facade) that may have introduced bugs. (Too early to
tell).

Are the features working OK? Most
>importantly, is the documentation in sync
>with the changes so that I could try to get
>my self back in sync with the latest code
>base?? (Great idea, making Diane a committer!
>Get those docs whipped into shape!)

theres a few newer tasks/features undocumented but nothing is documented
wrong (that I am aware of).

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

Query -- status of 'current' ant...

[Ken Wood <kw...@i2.com>]

Our shop has been happily using ant 1.2 with
one minor mod (Conor's optional 'depend' task)
for many weeks.

I've tried to monitor the list, but between the
debates over the future direction of Ant, and
the changes to ant 'now', and all the other
debates, I've lost track of the 'big picture'
(or the small picture, as the case may be...)

How is the current CVS version of ant? Is it
stable? Are the features working OK? Most
importantly, is the documentation in sync
with the changes so that I could try to get
my self back in sync with the latest code
base?? (Great idea, making Diane a committer!
Get those docs whipped into shape!)

I will not move our shop forward to a later
version of ant until I've had some experience
with it, and have a sense that it is 'value added'
to move forward. So I want to start 'evaluating'
ant all over again to see what the current version
can do for me.

Thanks!

-ken

RE: The two views of Ant's future direction

["Rosen, Alex" <ar...@silverstream.com>]

> I have been there and done that
> (mainly with c/c++ projects thou ...) and NEVER want to go
> there again and
> would encourage everyone to avoid it like the plague ;) My
> make files were
> infested with that evil a4 language and seriously I thinking that
> allowing/encouraging scripting in large projects is a great
> disservice to our users.

I respect this experience a great deal, because it's a lot more than I have.
However, it's worth noting that you (presumably) didn't try the alternative -
using no scripting - so we don't know if that would have turned out better or
worse. For Ant, that would mean either using XSLT (I can't imagine that would
have been more pleasant), or writing Java tasks for every procedural thing
(which is cleaner but more heavyweight, esp. for smaller projects).

--Alex

Re: The two views of Ant's future direction

[Peter Donald <do...@apache.org>]

At 11:12  15/1/01 -0800, Diane Holt wrote:
>In reading through all the mail regarding "Ant is/should-be a scripting
>language" vs. "No it's not and never was and never will be", I've been
>wondering if there's any room for compromise. I'm wondering if we could
>have the true-to-the-nonscripting-purists' vision of Ant as Basic Ant,
>then have the scripting-capabilities as extensions to that. Would it need
>another name? I don't know (but 'extant' comes to mind). Would it need to
>be a separate project? I don't know (clearly, 'extant' would be dependent
>on 'ant'). 

It's an option - maybe we could add an extra task-lib at Ant2.x time that
had these features. As long as I didn't have to support it then fine ;)

>Should Ant2 allow for the possibility of being extended to
>include the types of tasks such as <if>, <for>, <case>? I think so.

definetly. I have actually implemented it for my proposal but I didn't want
to submit it because it may invoke the wrath of the Ant gods ;)

>For simple projects,
>basic Ant would be all that would be needed -- but for large, complex
>build systems, Extended Ant could be used.

I suspect this is the exact reason why many people would oppose it. For
simple projects it is okay to use scripting as it does not increase
complexity however as projects become larger complexity increases. So using
scripts in a complex situation is just wrong IMHO because it makes them so
much more difficult to maintain and alter. I have been there and done that
(mainly with c/c++ projects thou ...) and NEVER want to go there again and
would encourage everyone to avoid it like the plague ;) My make files were
infested with that evil a4 language and seriously I thinking that
allowing/encouraging scripting in large projects is a great disservice to
our users.

I know as it stands there is issues in Ant1.x mainly as it evolved. However
with Ant2.0 we have a do-over so we can do things the *right* way. With
better Ant tasks/task structure I am under the impression that most of the
difficulties in Ant1.x can be eliminated (or at least I hope). For Jasons
case I can't see any problems using Ant2.0 and no scripting assuming
everything makes it in featurewise. For your case it is difficult because
of different JVMs and delicate ordering but I believe with unification of
property namespace to include filesets etc then it could be achieved.

One thing that would be great for your case is the ability to use embedded
evaluations. This is a common pattern in make but not used in ant. For
example consider the following

<property name="red.src" value="..." />
<property name="red.bin" value="..." />
<property name="red.dist" value="..." />
<property name="red.docs" value="..." />
<property name="red.lib" value="..." />

<property name="blue.src" value="..." />
<property name="blue.bin" value="..." />
<property name="blue.dist" value="..." />
<property name="blue.docs" value="..." />
<property name="blue.lib" value="..." />

<target name="...">

  <ant-call target="foo">
    <param name="color" value="red" />
  </ant-call>

  <ant-call target="foo">
    <param name="color" value="blue" />
  </ant-call>

</target>

<target name="...">

  <echo message="Task that compiles and builds ${${color}.src}" />
  ...

</target>

Would almost work for you. It would break some cases (namely when
inter-color groups are dependent) but these few cases could be "fixed" by
xslt/other.


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