RE: [PATCH] refactoring of javac task into factory

[Jose Alberto Fernandez]

Title: RE: [PATCH] refactoring of javac task into factory

I think one of the areas in which the ANT2.0 discussion has been lacking, is in the area of

configurability of the ANT environment. We have spend a lot of time talking about how to

find or add tasks to the system, how to ser the classpath, etc. But we have really not talked

about how to configure/taylor ANT to a particular users preferences.

 

The current mechanism of "ant.properties" file, I do not think is really usefull since it is based

on "magic properties". I have heard over and over about CSS and XSLT but we really have no clue

how any of the proposals can use such technology. To start with, this transformations would have to be applied before ANT itself consumes the XML file and producess a Project instance.

 

How this user preferences will apply in the case of IDE/GUI tools? Notice thateven from an IDE we need to be able to ultimately generate build files that are not only standard but that are customizable by others.

 

I think this really needs some thought.

 

Jose Alberto

-----Original Message-----
From: Jay Glanville [mailto:[EMAIL PROTECTED]
Sent: Sunday, December 17, 2000 10:42 AM
To: [EMAIL PROTECTED]
Subject: RE: [PATCH] refactoring of javac task into factory

> -----Original Message-----
> From: Peter Donald [mailto:[EMAIL PROTECTED]]
> Sent: Friday, December 15, 2000 10:48 PM
> To: [EMAIL PROTECTED]
> Cc: Ant-Dev (text)
> Subject: RE: [PATCH] refactoring of javac task into factory
>
>
> At 10:37  15/12/00 -0500, Jay Glanville wrote:
> >;-) I think we have a difference of opinion as to the
> definition of a magic
> >property. ;-)  To me, a property is magic if it is implicit.
>  A property is
> >magic if the task using it doesn't get the information from
> it's attribute
> >values.  In my patch, the task does not have to rely on the
> existence of a
> >"global variable" (ie: a system property), it gets all it's
> information from
> >it's attributes.
>
> Ahh but you advocated the use of a global variable to solve
> the problem.
> Remember? ;) You wanted the attribute to be assigned via a
> global variable.
> Now the particular name and even existence of such a property would be
> project specific. So you seem to be advocating a magic
> variable that can
> change at any time ;) It doesn't matter if the mapping from
> magic variable
> to attribute is explicit for it would functionally and
> conceptually be much
> the same.

Lets not forget one of our goals - to reduce/eliminate our dependence on magic variables.  If we can get to the point where we can say that Ant doesn't use magic variables, then we can make the statement that, logically (not functionally), parameters do not have global scope.  I.e.: if the tasks don't use parameters directly (they only get their information for their attributes or nested attributes) then parameters only have logical scope within the build.xml file.  This would be analogous to a method variable (in the procedural world) or an instance variable within a class.

> This kind of approach may be applicable to certain facades
> (such as the
> javacc compiler facade) but it is not applicable to javac
> where indidual
> developers preferences make little difference to build.
>
> >> >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.
> >>
> >> right - but I think we can do it better someother way ;)
> >
> >Like?
>
> At one stage there was a proposal for CSS mapping. So you
> would apply a CSS
> sheet to the build file. Like
>
> javac.compiler=jikes
>
> javac.jikes
> {
>   class: org.apache.ant.taskdefs.java.Jikes;
>   pedantic: true;
>   depend: true
> }
>
> Or someother such thing. You could overide it in build file
> by manually
> setting attributes but for all other purposes it did it
> "magically" via style.
>
> Not sure what became of proposal (if anything ?)

Very interesting proposal.  I hadn't thought of that.  Obviously, I didn't participate in the original discussion.  My only concern would be that this would add an extra layer of complexity to a build mechanism.  But, before you protest, this is only my impression.  I haven't fully thought through the implications of such a proposal.  Personally, I believe in the KISS theory, and thus I dislike changes that will add complexity without adding large amounts of functionality.  But, like I said before, I haven't thought through the implications of such a proposal.

> >To me, a magic property is analogous to a global variable in
> C.  If you
> >designed your code right, there were very few needs for
> global variables.
> >To me, attributes in ant are analogous to parameters in a
> method, where the
> >task is the method.  If I can, I'd like to remove global variables.
>
> Right. But your solution involved passing in a global variable as a
> parameter. Except the name of global variable is potentiall
> different in
> each different project, as is the existence of global
> variable. Except most
> developers want the global variable so ...
> ;)

JDGlanville