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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
