Defining task-specific properties - what "namespace" should I use?

[Nico Seessle <ni...@seessle.de>]

Hi all,

Javac (jikes) uses some properties to set options which are available only
to jikes and not the other compilers. Jikes uses for example
"jikes.class.path" and "build.compiler.(warnings|pedantic|emacs)".

If I'm going to define use properties for some other tasks (currently the
VSS one's as I'm extending these to also do history, checkout/in, label)
should I use "what I like" or should I (we) define that every task which
chooses to also accept properties as it's attributes should use something
like "ant.<defined task name>.theProperyName" (or something else?).

As an addition this could be further extended in a way that a task doesn't
need to look for the property explicitly, but ant could use these properties
to configure the tasks if the attribute is not explicitly set in the
build.xml. I know that one could do this by defining a property and using
'attribute="${property}"' so this would not really be an addition to ant and
therefor many people possibly won't like it :-)

Even if you don't like it I would like a suggestion on "what property-name
should I use if my task would like to use one" because the VSS-tasks would
mostly use the same settings for 'ssdir' (specifiying the location of VSS)
and 'login' (the username/password) to use for access and it seems much less
error-prone to specify these only once.

What's your opinion?

Nico

Re: Defining task-specific properties - what "namespace" should I use?

[Stefan Bodewig <bo...@bost.de>]

>>>>> "CM" == Conor MacNeill <co...@m64.com> writes:

 CM> Such configs could be defined in ${user.home}/.antconfig.xml.

I agree, especially in using an XML file instead of a properties file
to configure this.

 CM> It could even use some form of if processing

 CM> <taskconfig task="jspc"> 
 CM>   <implementation task="wljspc" if="weblogic.available"/> 
 CM>   <implementation task="jasper" if="tomcat.available"/> 
 CM> </taskconfig>

Looks great at a first glance, haven't thought abut the details yet
though.

Stefan

RE: Defining task-specific properties - what "namespace" should I use?

[Conor MacNeill <co...@m64.com>]

> -----Original Message-----
> From: Stefan Bodewig [mailto:bodewig@bost.de]
>
> But I don't feel comfortable with adding magic properties for
> situations like the javac/jikes one in general. Unfortunately I don't
> have a better solution for all situations at hand yet.
>

I agree. Such properties seem like backdoor entries into the task bypassing
the normal interface used to configure the task.

What I had thought would work would be to define configurations for certain
tasks

<taskconfig task="javac">
	<attribute name="compiler" value="Jikes"/>
	<attribute name="pedantic" value="on"/>
</taskconfig>

Effectively these attributes would be set by default for the task when it is
executed. They could then be overridden on a per-task basis. If you know
that Jikes can't compile something, you could force a classic compile, etc.

Such configs could be defined in ${user.home}/.antconfig.xml.

This could also be used for mapping tasks to concrete implentations which
may be useful in the J2EE arena where there are many vendor implementations
of various tools.

<taskconfig task="jspc">
	<implementation task="wljspc"/>
</taskconfig>

It could even use some form of if processing

<taskconfig task="jspc">
	<implementation task="wljspc" if="weblogic.available"/>
	<implementation task="jasper" if="tomcat.available"/>
</taskconfig>

We could also support nested elements which would automatically get added to
the task invocation too. This would allow you to configure options which
make sense in only some implementations

<taskconfig task="javac">
	<attribute name="compiler" value="Jikes"/>
	<jikes pedantic="on"/>
</taskconfig>

What do you think?

Conor

Re: Defining task-specific properties - what "namespace" should I use?

[Stefan Bodewig <bo...@bost.de>]

>>>>> "pd" == donaldp  <do...@mad.scientist.com> writes:

 pd> what I do is put

 pd>   <property file=".ant.properties"/> 
 pd>   <property file="${user.home}/.ant.properties"/>

 pd> at the top of each build file I use.

This is something we should think of for Ant in general. I.e. let Ant
search for ${basedir}/.ant.properties and ${user.home}/.ant.properties
and use them - making your property constructs unnecessary.

spec/core.html already had this idea.

But I don't feel comfortable with adding magic properties for
situations like the javac/jikes one in general. Unfortunately I don't
have a better solution for all situations at hand yet.

 pd> I haven't downloaded latest Ant with new dynamic properties but I
 pd> assume it is just a matter of reordering these in build file to
 pd> get this to work.

Don't think you'll have to do that. Properties are still immutable and
the first one wins - only this time we are talking about the first one
with regard to runtime instead of parser time. For <property> outside
of <target> runtime and parser time are the same so the shouldn't
change at all.

Stefan

Re: Defining task-specific properties - what "namespace" should I use?

[do...@mad.scientist.com]

On 14 Sep 2000, Stefan Bodewig wrote:

> >>>>> "NS" == Nico Seessle <ni...@seessle.de> writes:
> 
>  NS> Javac (jikes) uses some properties to set options which
>  NS> are available only to jikes and not the other compilers.
> 
> Yes and I'd really like to take it a very different approach to
> it. I've been kicking around this idea for quite some time now, how
> about
> 
> <javac ..>
>   <jikes pedantic="no" emacs="yes" />
> </javac>
> 
> which would be ignored if using a different compiler than jikes.
> 
> Would an approach like this fit your needs?

I don't like it and a lot of people would scream for my
blood. Thou I am a jikes advocate :P not everyone likes it
or has it and this could cause problems.

> Most notably I can easily setup my environment to always call Ant
> with -Dbuild.compiler.emacs=true now, while I'd need to ensure every
> build file has a <jikes> element nested into every <javac> with the
> appropriate setting of the emacs attribute to achieve the same effect.

what I do is put 

  <!--
    Give user a chance to override without editing this file
    (and without typing -D each time he compiles it)
  -->
  <property file=".ant.properties"/>
  <property file="${user.home}/.ant.properties"/>

at the top of each build file I use. This gives the user the
ability to specify both project specific and user specific
properties.

I define all my jikes settings in
${user.home}/.ant.properties as I use it in almost all
projects and project specific properties (like install
directory) in project specific .ant.properties.

Because .ant.properties come first I can also turn of
options like pedantic in projects that don't exactly follow
JLS recomendations (like Apache Turbine).

I haven't downloaded latest Ant with new dynamic properties
but I assume it is just a matter of reordering these in
build file to get this to work.

Cheers,

Pete

*--------------------------------------------------*
| Latrobe University,     | Does the name 'Pavlov' |
| Bundoora, Australia     |    ring a bell ?       |
*--------------------------------------------------*

Re: Defining task-specific properties - what "namespace" should I use?

[Stefan Bodewig <bo...@bost.de>]

>>>>> "NS" == Nico Seessle <ni...@seessle.de> writes:

 NS> Javac (jikes) uses some properties to set options which
 NS> are available only to jikes and not the other compilers.

Yes and I'd really like to take it a very different approach to
it. I've been kicking around this idea for quite some time now, how
about

<javac ..>
  <jikes pedantic="no" emacs="yes" />
</javac>

which would be ignored if using a different compiler than jikes.

Would an approach like this fit your needs?

I know it has some limitations if compared to a CSS based approach -
even compared to the property approach we currently take. 

Most notably I can easily setup my environment to always call Ant
with -Dbuild.compiler.emacs=true now, while I'd need to ensure every
build file has a <jikes> element nested into every <javac> with the
appropriate setting of the emacs attribute to achieve the same effect.

Stefan

Re: Defining task-specific properties - what "namespace" should I use?

[do...@mad.scientist.com]

On Thu, 14 Sep 2000, Nico Seessle wrote:
> If I'm going to define use properties for some other tasks (currently the
> VSS one's as I'm extending these to also do history, checkout/in, label)
> should I use "what I like" or should I (we) define that every task which
> chooses to also accept properties as it's attributes should use something
> like "ant.<defined task name>.theProperyName" (or something else?).

sounds good.

> As an addition this could be further extended in a way that a task doesn't
> need to look for the property explicitly, but ant could use these properties
> to configure the tasks if the attribute is not explicitly set in the
> build.xml. I know that one could do this by defining a property and using
> 'attribute="${property}"' so this would not really be an addition to ant and
> therefor many people possibly won't like it :-)

what you are talking about has been proposed before and many
people said it would be a good thing. Basically it equates
to CSS for ant build.xml sheets. The problem is that it
increases difficulty of learning ant and only the most
complex projects gain anything from using it. 

Much like make has IMake/automake/etc ant can have
equivelent front ends - many people have asked to make ant
just another programming language (like xslt) and others
like you think it should be styled. I agree these are
beneficial things in some cases but I doubt they will ever
make the ant code base because they are not 

* simple to use
* simple to understand

Thou I would love a front end (AdamAnt ???) that used this
CSS + adamant.xml -> build.xml and pass it through ant. Of
course no intermediate file need be created and in theory
you could stream SAX events between AdamAnt and Ant. So if
you want to do it go for it - but don't make Ant do it make
something built ontop of ant do it :P

> Even if you don't like it I would like a suggestion on "what property-name
> should I use if my task would like to use one" because the VSS-tasks would
> mostly use the same settings for 'ssdir' (specifiying the location of VSS)
> and 'login' (the username/password) to use for access and it seems much less
> error-prone to specify these only once.
> 
> What's your opinion?

I like but please make it a tool built on top of Ant if you
do it :P

Cheers,

Pete

*--------------------------------------------------*
| Latrobe University,     | Does the name 'Pavlov' |
| Bundoora, Australia     |    ring a bell ?       |
*--------------------------------------------------*