ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Loughran <ste...@apache.org>
Subject Re: references: backwards compatibility
Date Wed, 18 Oct 2006 10:38:16 GMT
Dominique Devienne wrote:
>> Ok, I will get my id reference stuff ready.
>> I do not think that we need a commandline arg or a property, the
>> only thing that is needed is a warning like DD's
>>
>> Warning: Reference y has not been set at runtime, but was found during
>> build file parsing, attempting to resolve. Future versions of Ant may 
>> support
>> referencing ids defined in non-executed targets.
> 
> I'm confused... Are you saying we'll leave the loophole of accessing
> refs from non-executed targets, and just print a warning?
> 
> Ant should fail by default in this situation. If someone wants to run
> in full BC mode, perpetuating the old broken ref handling, they *must*
> explicitly say so to Ant, and it should not be the default mode. Since
> Steve says he doesn't want to fix these other builds, then it has to
> be something specified out the build, use a CLI switch or the setting
> of a user property as proposed by Stefan.
> 
> BC is important to me, but when keeping BC means breaking my least
> surprises motto, then BC is not my friend any more ;-) --DD
> 

Since the change went in, I found three build files of mine that were 
broken. All of  these were the erroneous

1. two cut and pastes of some code to evaluate and print a reference (I 
should macro it, I know, but then I'd need <ac:var>:-

   <target name="declare-compile.classpath"
       depends="declare-base.compile.classpath,m2">
     <path id="compile.classpath">
       <path refid="base.compile.classpath"/>
       <path refid="libraries.path"/>
     </path>
     <property name="compile.classpath.value" refid="exec.classpath"/> 
                               ** HERE **
     <echo 
level="verbose">compile.classpath=${compile.classpath.value}</echo>
   </target>

As this was just an echo, it was an error, but a harmless one. The fix

<property name="compile.classpath.value" refid="compile.classpath"/>

2. one build file had a target that had incomplete dependency ordering, 
and which really broke. I needed to add a depends target to get it to build.

Both of these were IMO bugs, and neither of these bugs would have been 
found without the recent changes. So, I think the changes were good 
-they found and fixed bugs in my code.

But a 'bug' that has existed for a long time, it can become a feature. 
And, for problem #2 above, until I fixed the build file, the project did 
work correctly. I had an implicit dependency on the bug.

I am all +1 for the change, and happy to fix my own build files. I just 
dont want people downstream to have to fix them for me. Which is what 
will happen whenever someone out there does try and take a shipping 
smartfrog source distro and rebuild it on ant1.7 beta 3. And you know 
who they will complain to, dont you? Me :)

This is why I am +1 for Peter's fix of a fallback state with a big 
warning message. it is a bug, but one that can be hard coded into 
projects. We should print out the message then point people at a wiki 
page covering the details and the actions

-do nothing: have your app break in future. If the build file is not 
yours, this is your first choice
-fix the reference to point to a valid reference (i.e. defect #1 above)
-get your dependencies right (#2)

Incidentally, on the topic of  'no to expansion of non-defined 
properties'. What, even in echo?
-steve



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org


Mime
View raw message