ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jay Glanville" <>
Subject RE: [PATCH] refactoring of javac task into factory
Date Sat, 16 Dec 2000 02:28:00 GMT
> -----Original Message-----
> From: Peter Donald []
> Sent: Friday, December 15, 2000 7:09 PM
> To:
> Subject: Re: [PATCH] refactoring of javac task into factory
> At 08:18  15/12/00 -0500, you wrote:
> >I have a patch that I hope the ant team will accept (please, 
> please, please
> >;-).  Basically, the gist of the work is my refactoring the 
> javac task into
> >a different architecture (proxy, factory, etc).  I have also 
> introduced
> >three new attributes for the javac task which I'll explain later.
> Very kewl ! ;)
> I haven't checked out the code but assuming it is good and no 
> one -1's this
> then I will check it in. However I won't have much time for a 
> bit so be
> patient ;)
> One thing thou is the compiler flag. 

Are you sure you mean "Flag".  To me, a flag is either up or down, thus
usually represented by a boolean.  The compiler attribute is a text field.

> I am not sure I like it ... as a
> matter of fact I don't like it. 
> It will now encourage users to create
> incompatable build files by hardwiring compilers into the the 
> build file ;(

I'm not sure I understand your concern.  It was my impression that we wanted
to get away from "magic properties" (the build.compiler is an example of
one).  It's relatively easy to go through the ant-dev archives looking for
"magic properties" to find people saying they want to reduce their usage.
The only way that I thought that we could get rid of them is to replace them
with explicit attributes of a task.

On the subject of the "creation of incompatable build files by hardwiring
compilers into the build file", let me show you how this new attribute
PREVENTS that!  Lets look at the following build.xml snippet:
   <property file="" />
   <property name="prop.compiler" value="modern" />
   <javac compiler="${prop.compiler}" .../>
What does this mean?  Without any property over-rides, then the modern
compiler is used.  If the "prop.compiler" property is over-ridden, (with
"jikes" for example) then the jikes compiler is used ... all without the
usage of magic properties!

Let me give you another example.  Lets say that some wants to use the
compiler from symantic (I think it's sj.exe).  But it's not currently
supported by the javac task.  They would write a class that implements the
CompilerAdapter interface that takes the provided information in the javac
task, and then do the work.  Lets say the user created this class and called
it in package myant.modifications.  How would they modify the
build.xml file?  They would simply need to supply the compiler attribute
with "myant.modifications.SJ" (or, in the code snippet above, over-ride the
"prop.compiler" property).  The ability to provide a classname for the
compiler allows much more flexibility for users where the core supplied
tasks don't meet their needs.

Currently, in order to be able to do this, a user either has to modify the class, or use the exec task, both of which are more of a
hard-wiring of the compiler to the build file then the usage of the
"compiler" attribute I've introduced.

> What does everyone else think ?

Does a vote for myself count, or is that implicit?  ;-)  You'll have to
excuse my British cheek.  I blame my parents.

> Cheers,
> Pete

In case you haven't noticed yet, if you have any other questions, I will be
quite happy to answer them as best I can.

Jay Dickon Glanville

View raw message