Immutable Properties in 1.1?

[Roger Vaughn <rv...@seaconinc.com>]

I just downloaded and started using Ant 1.1, and I have to say that I DO
NOT LIKE the fact that I can no longer redefine properties once
defined.  This, to me, is very painfully reminiscent of macro
definitions in Make (where the last definition in the file wins - and
NOT in target processing order.

I have to agree that the example given on the download page is worth
preventing, but I have been using redefined properties for perfectly
legitimate purposes - to simplify constructing sets of similar targets
in my builds.

For example, I do this:

<target name="jar1">
  <property name="jarfile" value="jar1.jar"/>
  <property name="includes" value="**/somefiles"/>
  <!-- some code that uses ${jarfile} and ${includes} -->
</target>

<target name="jar2">
  <property name="jarfile" value="jar2.jar"/>
  <property name="includes" value="**/someotherfiles"/>
  <!-- some code that uses ${jarfile} and ${includes} -->
</target>

In this example, the task code is exactly the same, allowing me to
easily create similar targets, or quickly replace code blocks for many
targets at once.  The properties are treated as local variables and hold
all of the values that cause the individual targets to differ.  With
immutable properties, however, I have to custom-code each block and
cannot easily change the code executed without a lot of manual work - or
at least after spending just as much time coming up with some hefty
regexps to do it for me.

Some of this would be alleviated by allowing access to the project and
target names as properties (hint, hint...), but this still wouldn't
allow complete flexibility.

I vote for bringing back mutable properties.  I also vote for leaving in
access to the System properties.  The fact that "...all Java code has
access to the system property list via the java.lang.System class..."
doesn't do me a darn bit of good in the middle of an Ant build file --
it isn't Java code.  Certain properties such as "user.dir" and "os.name"
are extremely useful at build time.  I do not find access to these
confusing, as no good Java programmer should be redefining system
properties (user., java. and os.) anyway.

As an alternative, I might propose adding target-local variables that
behave like properties, but only within target scope.

Roger Vaughn

Re: Immutable Properties in 1.1?

[Roger Vaughn <rv...@seaconinc.com>]

Wonderful.  I'm happy with that.  Thanks!

Stefan Bodewig wrote:

> >>>>> "RV" == Roger Vaughn <rv...@seaconinc.com> writes:
>
>  RV> I read this as saying that even read access to the system
>  RV> properties is being removed.  Did I misinterpret?
>
> Yes and we'll probably need to clarify the documentation. Just go
> ahead and do an <echo message="${os.name}" />. It works.
>
> Stefan

Re: Immutable Properties in 1.1?

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

>>>>> "RV" == Roger Vaughn <rv...@seaconinc.com> writes:

 RV> I read this as saying that even read access to the system
 RV> properties is being removed.  Did I misinterpret?

Yes and we'll probably need to clarify the documentation. Just go
ahead and do an <echo message="${os.name}" />. It works.

Stefan

Re: Immutable Properties in 1.1?

[Roger Vaughn <rv...@seaconinc.com>]

Stefan,

This is in answer to the statement in the core spec in the latest source
distribution:

"Note: The current version of Ant allows the System property list to be
consulted for a return value if the property list doesn't satisfy the
requested property name. As all Java code has access to the system
property list via the java.lang.System class, this functionality is
considered to be confusing and to be removed."

I read this as saying that even read access to the system properties is
being removed.  Did I misinterpret?

I like your answer though - I believe we need read access, but write
access to system properties should definitely be prohibited.

roger



Stefan Bodewig wrote:

> For the lager part of this post, see another mail that should follow
> shortly.
>
> >>>>> "RV" == Roger Vaughn <rv...@seaconinc.com> writes:
>
>  RV> I also vote for leaving in access to the System properties.
>
> I don't get this. You do have full *read* access to them, you just
> cant override them. Or am I missing something here?
>
> Stefan

Re: Immutable Properties in 1.1?

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

For the lager part of this post, see another mail that should follow
shortly.

>>>>> "RV" == Roger Vaughn <rv...@seaconinc.com> writes:

 RV> I also vote for leaving in access to the System properties.

I don't get this. You do have full *read* access to them, you just
cant override them. Or am I missing something here?

Stefan

Re: Immutable Properties in 1.1?

[Roger Vaughn <rv...@seaconinc.com>]

Bravo.  Basically this is like subroutines for Ant.  (I know, I know, it's
more like XSL templates, but still...)  This feature would be *very*
welcomed.  I wanted this for years in Make, and lamented even the repetition
I had to do in Ant.  So for me, make that

+1

Jesse Glick wrote:

> Roger Vaughn wrote:
> > I have to agree that the example given on the download page is worth
> > preventing, but I have been using redefined properties for perfectly
> > legitimate purposes - to simplify constructing sets of similar targets
> > in my builds.
>
> I should mention that I have done some work on an experimental patch to
> the core (I know, hisses) which should permit you to specify templates
> for targets rather than concrete targets. The syntax is pretty simple,
> using regular expressions (not ideal but simple to understand and very
> flexible):
>
> <project name="foo" default="echo-hello" basedir=".">
>   <target pattern="echo-(.*)">
>     <echo message="I say: $[1]"/>
>   </target>
> </project>
>
> This should print "I say: hello". In other words, the target is really a
> template; it is instantiated on demand and $[number] variables in
> substitutable places within the target body are replaced by the
> corresponding regex match strings. If you have used Perl, sed, etc. then
> the idea should be pretty clear. That example is dumb of course but more
> to the point:
>
> > <target name="jar1">
> >   <property name="jarfile" value="jar1.jar"/>
> >   <property name="includes" value="**/somefiles"/>
> >   <!-- some code that uses ${jarfile} and ${includes} -->
> > </target>
> >
> > <target name="jar2">
> >   <property name="jarfile" value="jar2.jar"/>
> >   <property name="includes" value="**/someotherfiles"/>
> >   <!-- some code that uses ${jarfile} and ${includes} -->
> > </target>
>
> This would become:
>
> <project name="xxx" basedir="." default="all-jars">
>   <target name="all-jars" depends="jar1,jar2"/>
>   <target pattern="jar([0-9]+)">
>     <echo message="Running target $[0]..."/>
>     <someJarTask jarfileToUse="jar$[1].jar"
>                  includeList="**/someotherfiles-$[1]"/>
>   </target>
> </project>
>
> No property mutation or copy-and-paste required. For those familiar with
> GNU make, this is similar to use of % patterns in make targets, except
> more flexible (regexps vs. shell patterns, and multiple match
> substrings). You can have as many templates as you need; the first one
> which matches a required target name will be used.
>
> I would appreciate any thoughts on whether people would find this sort
> of thing valuable, or if there is an obvious way to get the same effect
> with Ant as it is. I guess you can run an Ant sub-project but that seems
> rather cumbersome. Hopefully the syntax does not appear too wretched.
> One caveat: <script> will not see targets from template unless they had
> been instantiated anyway; I do not see any way around this.
>
> BTW implementation of this is a headache: can I suggest for the future
> that ProjectHelper parse the document, *then* go through and construct
> targets and tasks (depth-first-search from root)? That would greatly
> simplify changes like this (at the expense of a small increase in memory
> at runtime). It would also be helpful when running Ant embedded in some
> other tool (parse one, run many). Especially since properties are set
> while parsing, which seems sort of a hack.
>
> -Jesse
>
> --
> Jesse Glick   <ma...@netbeans.com>
> NetBeans, Open APIs  <http://www.netbeans.org/>
> tel (+4202) 3300-9161 Sun Micro x49161 Praha CR

Re: Immutable Properties in 1.1?

[Jesse Glick <Je...@netbeans.com>]

Roger Vaughn wrote:
> I have to agree that the example given on the download page is worth
> preventing, but I have been using redefined properties for perfectly
> legitimate purposes - to simplify constructing sets of similar targets
> in my builds.

I should mention that I have done some work on an experimental patch to
the core (I know, hisses) which should permit you to specify templates
for targets rather than concrete targets. The syntax is pretty simple,
using regular expressions (not ideal but simple to understand and very
flexible):

<project name="foo" default="echo-hello" basedir=".">
  <target pattern="echo-(.*)">
    <echo message="I say: $[1]"/>
  </target>
</project>

This should print "I say: hello". In other words, the target is really a
template; it is instantiated on demand and $[number] variables in
substitutable places within the target body are replaced by the
corresponding regex match strings. If you have used Perl, sed, etc. then
the idea should be pretty clear. That example is dumb of course but more
to the point:

> <target name="jar1">
>   <property name="jarfile" value="jar1.jar"/>
>   <property name="includes" value="**/somefiles"/>
>   <!-- some code that uses ${jarfile} and ${includes} -->
> </target>
> 
> <target name="jar2">
>   <property name="jarfile" value="jar2.jar"/>
>   <property name="includes" value="**/someotherfiles"/>
>   <!-- some code that uses ${jarfile} and ${includes} -->
> </target>

This would become:

<project name="xxx" basedir="." default="all-jars">
  <target name="all-jars" depends="jar1,jar2"/>
  <target pattern="jar([0-9]+)">
    <echo message="Running target $[0]..."/>
    <someJarTask jarfileToUse="jar$[1].jar"
                 includeList="**/someotherfiles-$[1]"/>
  </target>
</project>

No property mutation or copy-and-paste required. For those familiar with
GNU make, this is similar to use of % patterns in make targets, except
more flexible (regexps vs. shell patterns, and multiple match
substrings). You can have as many templates as you need; the first one
which matches a required target name will be used.

I would appreciate any thoughts on whether people would find this sort
of thing valuable, or if there is an obvious way to get the same effect
with Ant as it is. I guess you can run an Ant sub-project but that seems
rather cumbersome. Hopefully the syntax does not appear too wretched.
One caveat: <script> will not see targets from template unless they had
been instantiated anyway; I do not see any way around this.

BTW implementation of this is a headache: can I suggest for the future
that ProjectHelper parse the document, *then* go through and construct
targets and tasks (depth-first-search from root)? That would greatly
simplify changes like this (at the expense of a small increase in memory
at runtime). It would also be helpful when running Ant embedded in some
other tool (parse one, run many). Especially since properties are set
while parsing, which seems sort of a hack.

-Jesse

-- 
Jesse Glick   <ma...@netbeans.com>
NetBeans, Open APIs  <http://www.netbeans.org/>
tel (+4202) 3300-9161 Sun Micro x49161 Praha CR

Re: Immutable Properties in 1.1?

[Jesse Glick <Je...@netbeans.com>]

Ken Liu wrote:
> BTW, the problem I see with using templated targets ala Jesse's patch is

"patch" -> "proposed patch" :-)

> that it would be difficult to define different "depends" for each different
> target, no?

Well, I was assuming that you would be able to parametrize depends lists
as well:

<target pattern="prepare-dir-(.*)">
  <somehowCleanIt path="sources/$[1]"/>
</target>
<target pattern="build-dir-(.*)-with-libs-from-(.*)"
        depends="prepare-dir-$[1]">
  <compileIt path="sources/$[1]"
             pullInJars="$[2]/*.jar"/>
</target>

Something like that. Now run targets like
"build-dir-foo/bar-with-libs-from-miscutils". If you have different
*kinds* of dependencies for the different targets, you would need one
template per kind of dependency, I guess.

-Jesse

-- 
Jesse Glick   <ma...@netbeans.com>
NetBeans, Open APIs  <http://www.netbeans.org/>
tel (+4202) 3300-9161 Sun Micro x49161 Praha CR

RE: Immutable Properties in 1.1?

[Ken Liu <kl...@auctionlogic.com>]

Roger,

I did actually take Glenn's advice this morning (thanks Glenn!) and modified
his XSL stylesheet example to redo my build file.  However, the change made
my build file is IMHO not a good thing:

BEFORE:
<!-- AuctionManager target -->
<target name="AuctionManager.compile" depends="init,TXManager.interface">
	<property name="ejb.basedir" value="com\auctionlogic\auction"/>
	<property name="ejb.basename" value="AuctionManager"/>
	<property name="ejb.includes" value="*.java"/>
	<ant antfile="${include.dir}/ejb-build.xml" dir="." target="ejb.compile"/>
</target>
<target name="AuctionManager.build" depends="init,AuctionManager.compile">
	<property name="ejb.basedir" value="com\auctionlogic\auction"/>
	<property name="ejb.basename" value="AuctionManager"/>
	<ant antfile="${include.dir}/ejb-build.xml" dir="."
target="ejb.descriptor"/>
	<ant antfile="${include.dir}/ejb-build.xml" dir="."
target="ejb.container"/></target>



AFTER:
<!-- AuctionManager target -->
<target name="AuctionManager.compile" depends="init,TXManager.interface">
	<ant antfile="${include.dir}/ejb-build.xml" dir="." target="ejb.compile">
		<property name="ejb.basedir" value="com\auctionlogic\auction"/>
		<property name="ejb.basename" value="AuctionManager"/>
		<property name="ejb.includes" value="*.java"/>
	</ant>
</target>
<target name="AuctionManager.build" depends="init,AuctionManager.compile">
	<ant antfile="${include.dir}/ejb-build.xml" dir="."
target="ejb.descriptor">
		<property name="ejb.basedir" value="com\auctionlogic\auction"/>
		<property name="ejb.basename" value="AuctionManager"/>
	</ant>
	<ant antfile="${include.dir}/ejb-build.xml" dir="." target="ejb.container">
		<property name="ejb.basedir" value="com\auctionlogic\auction"/>
		<property name="ejb.basename" value="AuctionManager"/>
	</ant>
</target>



So you can see that nesting the properties in the <ant> tag potentially
creates more work for me from a maintenance standpoint because now I have
two sets of identical properties for each target.  It's also more difficult
to read.  Yes, its a Bad Thing.

Basically what I want is not necessarily mutable properties...I just need a
way to create variables so I can parameterize a reusable section of build
code.  Yes, subroutines for Ant.  Any suggestions?

BTW, the problem I see with using templated targets ala Jesse's patch is
that it would be difficult to define different "depends" for each different
target, no?

Ken

Re: Immutable Properties in 1.1?

[Roger Vaughn <rv...@seaconinc.com>]

Ken,

I just saw them.  As you'll see in my other post, I'm not thrilled about the
workaround proposeds.  Shall we form the Coalition for Access to Mutable
Properties (CAMP)?  ;-)

roger

Ken Liu wrote:

> Roger, you can see from the recent thread "help! Can't I set a <property>
> more than once in a build file?" that I had the same kind of problem.  I set
> up some properties and then call an <ant> target that takes those properties
> as parameters.
>
> I'm with you, target-local variables/properties would be great.
>
> Ken
>
> > As an alternative, I might propose adding target-local variables that
> > behave like properties, but only within target scope.
> >
> > Roger Vaughn
> >
> >
> >

RE: Immutable Properties in 1.1?

[Ken Liu <kl...@auctionlogic.com>]

Roger, you can see from the recent thread "help! Can't I set a <property>
more than once in a build file?" that I had the same kind of problem.  I set
up some properties and then call an <ant> target that takes those properties
as parameters.

I'm with you, target-local variables/properties would be great.

Ken


> As an alternative, I might propose adding target-local variables that
> behave like properties, but only within target scope.
>
> Roger Vaughn
>
>
>