ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jose Alberto Fernandez <>
Subject Re: What flavour of scripting?
Date Wed, 01 Mar 2000 22:44:11 GMT

Pierpaolo Fumagalli wrote:

> wrote:
> >
> > Pier wrote:
> > > Ok, I won't continuing debating that since how Ant works right now is
> > > more than fine (so I can just forget to update it in the future) but,
> > > really, ARE YOU SERIOUS about that?
> > > Because if so, I'll just get my Jar and let you people deal with it any
> > > further... You're really adding an ELEPH in front of the ANT...
> >
> > Bye,  Pier!  ;-)
> C'ya :/
> > the not too distant past, nested tags were thought to add
> > incredible complexity to the implementation, or make ant more difficult to
> > learn and use. Thankfully, we were wrong.  If you care to, take a look at
> > processNestedProperties in ProjectHelper, and at MatchingTask.
> Dealing w/ trees is one thing... With a Turing complete language is
> different... Anyway, you don't have to convince me... I ALREADY HAVE
> what I want... I just need to remove half of the taskdefs in there
> (since I don't use 'em) and fix a couple of issues. Then, I'm a happy
> camper...
> I'm not voting -1... I'm just saying that _I_ am not going any further.
> > Then take a look at cocoon's current build.xml.  Via dependencies, the
> > prepare-src target is essentially composed of a series of optional tasks
> > which copy selected portions of the java code to a separate directory tree,
> > and the compile task will compile that separate tree into a third location.
> > I guess that this is OK when there are only three optional subsystems, but
> > take a look at what needs to be done if a fourth subsystem is added - an
> > <available> task will need to be added, a complete new target with a
> > copydir task will need to be added.  The dependencies on prepare-src will
> > need to add this target.  Finally, another exclude will need to be added to
> > the copydir task inside of prepare-src itself.
> I know how the Cocoon makefile is done, and why Stefano changed that. I
> would have done it differently, but it's not important. This is an
> issue: To build something, sometimes, you need to be dependant on the
> ability to access certain libraries. BUT this is not like having
> JAVASCRIPT inside builds...
> > BSF currently has support for over a dozen optional scripting languages.
> Please, don't tell me... Because I am just getting acquainted to Java
> (wich is, in my definition, not a scripting language).
> On my Linux box I had to install PERL the day I tried out BugZilla for
> the Jakarta and XML projects, and almost got a heart attack. BugZilla
> installed on Locus, PERL removed from my system (and I don't want to see
> TCL/TK, tcsh, or whatever that is not the only scripting language I know
> - and respectfully hate - bash...)
> > My feeling is that the approach described above doesn't scale well.
> >
> > With nested tags, one can directly add
> >    <include name="**/javascript/**" if="javascript.present">
> > or, conversely,
> >    <exclude name="**/javascript/**" unless="javascript.present">
> >
> > I feel that this is significant improvement.  The scripts are smaller,
> > easier to understand, and easier to modify.
> It's a significant improvement for YOU ALL, not for me. For me? Just a
> useless complication, something else I'd have to know...
> The only thing I need? A small modification to the javac task:
> <target name="compile"
>         depends="whatever"
>         requires="org.apache.myclass.TheOneINeedToCompile
>         action"[fail/ignore]"/>
> Before calling that target I check wether I can do a "Class.forName()",
> if I can't, I fail or ignore depending on the action.
> Nothing more.

This to me is crazy. Everyone of us is inventing its own version of the javac
task to fulfill their own needs. The end result is a gazillion of tasks that
no one knows what are they for. The whole point of having a way to
combine tasks in ANT is to avoid of versions of the same taks just
to solve my little corner example. Otherwise build.xml files will become less
understandable than Makefiles.

> > One still needs to code an <available> task.  Actually, in my original
> > implementation, I hadn't taken the time to understand what Stefano had
> > added, so on coded the class you were looking for directly on the include
> > or exclude element, but I have now changed it to be more consistent.
> > Besides, I find that explicitly naming the variable gives an opportunity
> > for the script to become more understandable.
> You see? I don't even know what IS the "available" task...
> Maybe I'm just an old primitive with no concept of programming, but,
> whatever, I don't care... I just have what I need...
> > At this point you might be wondering why I am bringing this up.
> I perfectly see why... We have different ideas, and probably different
> requirements. It's like buying a car: I need 4 reliable wheels, with an
> exterior I like. I bought a nice tiny little Tigra
> <>. My dad needs
> to carry stuff, and needs a more "representative" car: he got a big
> Volvo V70 <>
> You need a volvo, I need a tigra, you need those features, I don't need
> them, and more importantly, I don't want to see, use or having anything
> to do with them. My Ant jar is 180kb uncompressed. I don't need 50k of
> those, and w/ JAXP now I don't even care about all the parser issues. In
> my short experience of java programming, I'm not needing anything else.

But other need more. I think ANT is not for your eyes only.

> > First, I'd like to ask that you and others not to be so quick to prejudge
> > the conceptual cost (both in implementation and usage) associated with
> > various proposals.
> I don't have any prejudice. Apart from saying that I don't need anything
> more, I'm not binding you (also because I'm NOT an ANT developer, I
> contributed 4 lines of code and my veto would be totally ridiculous).
> Evolve or revolve, delete or destroy, enhance or invent... it, I'm
> happy... And if you are successful, hey, it's good for the Apache
> "Branding"...
> > Second, and more importantly, I am going to continue to try to steer this
> > conversation towards requirements.  Please, everybody, tell me WHAT you are
> > trying and WHY what you are proposing is the simplest solution to your
> > problem.  Abstract examples with foos and pearly gates just don't do it for
> > me.
> My requirements?
> - rmic
> - javac
> - jar
> - javadoc

So what do you do when your next project requires some more tasks?

> (those things because they could have very long command lines)
> or they can be also grouped in a common task:
> -exec that spawns a process and watches it
> (even if it would be nice to hack, as we do, inside directly the java
> main() methods or their equivalents...)
> - copy (file/trees) with the ability to exclude files/dirs (**/CVS/)
> - delete (file/trees)
> (the windows implementation SUCKS!)
> - ability to ignore a task if I don't have a class in my classpath
>   (or it could be EVEN in the javac task, I don't care)
> - ability to (obviously) produce the output of the different tasks, and
> adding, at the end a nice line Saying "I made it" or "D'oh!" (so I can
> filter my mail when I'll start my automated nightly builds)
> I'm glad Stefano came up with a TAR thing, but, I mean, it takes less
> than zero to copy my structure in a "dist/" directory and type:
> "tar -cvf project.tar dist/ ; gzip -9 project.tar"
> or clicking on the folder of my windoze box and WinZipping it...
> You know what made ME and some of my friends REALLY happy today? This
> class:, spawning a process and duplicating the standard
> output/error of that to a file. The stinkin' default windows command
> line doesn't support stderr redirection, and in unix it takes me always
> more than a minute to remember that the right command to place after the
> unobvious list of pipes is "tee" :) I wrote it on the car while they
> were driving me out to a restaurant, and I added a couple of comments
> (hey, it also have comments!!!) getting back from it. It works, we're
> happy, and it solves all the cases seen so far... (Windo$H people, get
> it, it's a MUST)
>         Pier
> --
> --------------------------------------------------------------------
> -          P              I              E              R          -
> stable structure erected over water to allow the docking of seacraft
> <>    <>
> --------------------------------------------------------------------
> - ApacheCON Y2K: Come to the official Apache developers conference -
> -------------------- <> --------------------
>   ------------------------------------------------------------------------
>                    Name:
>    Type: application/x-unknown-content-type-Java.Source
>                Encoding: base64

 Jose Alberto Fernandez               500 Oracle Parkway, M/S 9op4
 Development Manager                  Redwood Shores, CA 94065
 ORACLE Corp.                         Phone: (650) 506-8830
 Java Products Group                  Fax: (650) 506-7303
 Languages & Obj-Relational Tech      Email:

View raw message