ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pierpaolo Fumagalli <p...@apache.org>
Subject Re: What flavour of scripting?
Date Wed, 01 Mar 2000 11:51:18 GMT
rubys@us.ibm.com 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 :/

> Seriously...in 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.

> 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
<http://www.europe.opel.com/cars/tigra/intro/index.jhtml>. My dad needs
to carry stuff, and needs a more "representative" car: he got a big
Volvo V70 <http://www.volvocars.it/pp/newV70/default.asp>

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.

> 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

(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: Streams.java, 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
<mailto:pier@betaversion.org>    <http://www.betaversion.org/~pier/>
--------------------------------------------------------------------
- ApacheCON Y2K: Come to the official Apache developers conference -
-------------------- <http://www.apachecon.com> --------------------
Mime
View raw message