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 Thu, 02 Mar 2000 12:12:41 GMT
rubys@us.ibm.com wrote:
> 
> Sound to me that what you are asking for is a modification to target, not
> javac.

Can be wherever, better in the target, but... I don't care..

> It also sounds to me like you already have what you need, though
> perhaps not in the form that you describe.  Here's how you would do it
> today:
> 
>  <available property="myclass.present"
>     classname="org.apache.myclass.TheOneINeedToCompile" />
> 
>  <target name="compile"
>      depends="whatever"
>         if="myclass.present" />

Yes, as it's used by Cocoon, I know it... Are you reading my emails? I
said that already! What I don't remember saying is that I don't like the
"property" thing, but I can live with that...

> Note: I'm not sure why you need an action="[fail/ignore]", care to
> enlighten me?

fail: fail with an error if the class is not there (default)
ignore: silently ignore that <target> or that <javac>, like if it was
successful. And it's just pertinent to the <javac> task, did I place it
in <target> ??? My mistake if so.

> The problem I have (or had) is that the javac task is too powerful.  For a
> while, I couldn't build ant because javac would pick up all java files it
> found, including ApacheParser.  The solution I opted for at the time was to
> fix ApacheParser to use introspection. 

Geee kid, you're complicated :) :) Introspecting classes to see if you
can build something? That's flexibility syndrome (however it's written)

> A much better solution, IMHO, based
> on what can be done with Ant today would be to add the following to ant's
> build.xml.
> 
>   <available property="xerces.present"
>       classname="org.apache.xerces.parsers.DOMParser" />
> 
>   <javac srcdir="${src.dir}" destdir="${build.classes}"
>          classpath="${classpath}">
>       <exclude name="**/ApacheParser.java" unless="xerces.present">
>   </javac>
> 
> I'm hoping that with the above concrete example, you will have an "AHA!"
> experience, and decide that this is not merely a "useless complication".

I have an AHA! I believe that we all agree that javac needs to be
invoked conditionally depending on the presence (or not) of a class.
That's the only "if" I have... But that's not a real if... It's a
dependancy (like invoking a <target> depending on the name of another
target is another if. "if I have to call <target name="build"> then I
need to call <target name="copy"> before that).

What I did before that was available?
For ant I would have done something like (I write it down in plain text
because I don't remember the exact build attributes)

<target name="copy.sun">
  copy "src/**/SunParser.java" in "build/src"
</target>
<target name="copy.apache">
  copy "src/**/ApacheParser.java" in "build/src"
</target>
<target name="copy">
  copy all in "src" in "build/src" excluding "src/**Parser.java"
</target>
<target name="build" depends="copy.sun, copy.apache, copy">
  javac all in "src"
</target>
<target name="sun" depends="copy.sun, copy">
  javac all in "src"
</target>
<target name="apache" depends="copy.apache, copy">
  javac all in "src"
</target>

And on my cmd line, I type "ant build apache", you "ant build sun"

> P.S.  All kidding aside, I would be greatly troubled if you chose to grab a
> version of the ant.jar and drop out.  For two reasons:

Hey, I'm _NOT_ forking... I'm dropping out... I guarantee that...

> 1) A number of changes being discussed here are not backwards compatible.

... Hm. So?? I'll be the old moron with the old build files, you'll be
the smart flexible guys with the super-duper programmable build
scripts...
Ant is small enough to be distributed with the binaries I build with...
And if one day my friend Stefano will build the new scripted build files
for Cocoon... he will have to maintain them, because I will not :) :) :)
:) :)

> Example: Duncan and Stefano are advocating making properties defined inside
> a target local to that target.

That's a cute change... It passed by and didn't noticed it...
I don't really even see why I would like to set properties dinamically
(grin, thinking, no, I don't need it), why would you do that?

> The net is that over time you will likely find it more difficult to
> share your build instructions with others.

Until today, I just said "do it yourself" or made a batch file for java
code, so, it's better than that. I'm happy.
I just include _EVERYTHING_ (also a small ant, the build.xml) within an
executable JAR. And with JAXP, I just need an XML-enabled VM. I'm all
set. You can get sources, build files, ALL and simply execute a Jar,
that creates another JAR that you place in /jre/lib/ext, OR, you expand
it and work with the sources, buildfiles, all, and then you regenerate
another "complete" jar...

> 2) Your dropping out would mean a significant reduction in the number of
> ideas in the gene pool (or meme pool).  It would be all too easy for us to
> go off the deep end, either by steadily accumulating tasks that were needed
> to get the job done or by getting too enraptured in the power of one
> feature or design pattern. 

I never contributed, apart a some parser abstraction thing, for which I
was flamed heavily because you weren't able to build anything anymore
(and so I believe who started the whole fight at the beginning, it's my
fault, just look at the beginning of your email, I'm flamed once again,
by myself.. OH SHIT!)

> One of ant's main attractions is that it is
> simple.  Keep keeping us honest.

And you think that inserting JAVASCRIPT or whatever other language's
there will make it simpler? Maybe I'm nuts, or a moron, but I really
don't understand it.

> Just remember that (and I believe that this is one of Murphy's laws), when
> all is said and done, a hell of a lot more is said than done.

If you go on replying, I won't stop posting, because I believe in what I
think, until the code moves into the repository. On that day, I'll be
gettin my CVS version and pull myself out...

> As applied here (and as Martha Stewart would say), "It's a good thing!".

That's applied to M.S. meatloaf (try to cook it, "It's _REALLY_ a good
thing!") discussion is good, but in this case, your decision is binding,
at least for me...

	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