Re: Ant 2.0
Dale Anson wrote: I've also ran into this problem, which prompted the task that is now in ant-contrib as a solution. It works a lot like Java's assert in that it can be turned on or off either through a command line parameter or by a property. It is a task, so does require build file modification, but it is useful for making sure that a property is set or set to the right value at a particular spot in the build. yes, assertions. I see. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Ant 2.0
I've also ran into this problem, which prompted the task that is now in ant-contrib as a solution. It works a lot like Java's assert in that it can be turned on or off either through a command line parameter or by a property. It is a task, so does require build file modification, but it is useful for making sure that a property is set or set to the right value at a particular spot in the build. Dale Stefan Bodewig wrote: On Sun, 08 Feb 2004, Steve Loughran <[EMAIL PROTECTED]> wrote: One thing that was voted on (positively, I recall), way way back in time, was for Ant2.0 to fail on undefined properties. Although I've never looked into it, can't you already have it with a custom PropertyHelper? If you can ensure that your custom property helper is the last one that gets called - and that it never gets called for know properties - you should be there. Provide this property helper and maybe add a new command line switch as syntactic sugar, done. 3. But there would be a non-throwing expansion method for code that explicitly wanted to not fail on missing strings in their . The PropertyHelper could deal with it. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Ant 2.0
> > One thing that was voted on (positively, I recall), way way back in > > time, was for Ant2.0 to fail on undefined properties. > > Although I've never looked into it, can't you already have it with a > custom PropertyHelper? If you can ensure that your custom property > helper is the last one that gets called - and that it never gets > called for know properties - you should be there. > > Provide this property helper and maybe add a new command line switch > as syntactic sugar, done. > > > 3. But there would be a non-throwing expansion method for code that > > explicitly wanted to not fail on missing strings in their . > > The PropertyHelper could deal with it. > > Stefan BTW, in proposal/embed is a PropertyHelper which creates a list from a XML file and an XPath. Reading that was my first step on PropertyHelpers... Jan
Re: Ant 2.0
Steve Loughran wrote: I suppose the problem was that undefined properties were just ignored, and you had a hard time debugging this ( I had similar problems many times ). you can get those messages if you crank up the verbosity, but you still need to go through the lines and look at them. I suppose if we had a better listener model then I could run a listener to filter for the relevant message topic and highlight them. We can increase the level ( warn ? ) and make them more visible ( caps, underline, etc ). Actually - one of the problems I have with the current ant logging is that the default verbosity is a bit too big and sometimes hard to follow. It would be nice if warnings would display the build file and line number, and some progress events ( like targets with no output ) would be moved to verbose. I tought commons-logging logger is a solution, but it's too complicated to configure. I would preffer a warning for undefined properties outside echo/fail instead of the option to fail - since in the second case it may fail in too many build.xml files, forcing people to just disable it. I'd have the default of non-strict; fail-on-undefined would be an option people could turn on for better diagnostics. My point was that it's better to have the default "warn" instead of having this as an option and fail. If the behavior is "fail" - it clearly has to be an option, and most people will not be able to use it ( or even know about it - who reads all the manuals ? ). If the behavior is "warn" - with maybe an option to silence it - people could avoid a lot of errors and it would be easier to debug. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Ant 2.0
On Sun, 08 Feb 2004, Steve Loughran <[EMAIL PROTECTED]> wrote: > One thing that was voted on (positively, I recall), way way back in > time, was for Ant2.0 to fail on undefined properties. Although I've never looked into it, can't you already have it with a custom PropertyHelper? If you can ensure that your custom property helper is the last one that gets called - and that it never gets called for know properties - you should be there. Provide this property helper and maybe add a new command line switch as syntactic sugar, done. > 3. But there would be a non-throwing expansion method for code that > explicitly wanted to not fail on missing strings in their . The PropertyHelper could deal with it. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Ant 2.0
Costin Manolache wrote:
Steve Loughran wrote:
I know Ant2.0-the-rewrite is essentially dead (and essentially
obsolete through evolution in the codebase), but I still think we
ought to consider using the name as and when the time is appropriate.
If we add enough interesting stuff to 1.7, it could be the time.
Please, not again :-)
ok.
One thing that was voted on (positively, I recall), way way back in
time, was for Ant2.0 to fail on undefined properties.
Having just struggled with a build file refactor that introduced the
problem, a problem I only dealt with by resorting to IntelliJ's
property-aware ant file editor, I am starting to think the
fail-on-undefined property mechanism is good.
But at the same time, those echo statements with undefined properties
are ubiquitous, and they need to stay in. And we need the option of
turning strict property evaluation off or on.
My preferred way to do this would be to
1. either or both of
a new command line option,
a new property to set.
to turn strict property evaluation on.
The nice thing about these two is that they can be applied to existing
files. The property set tactic would let you use build.properties to
set the flag, and enable inline in projects that will still work in
ant 1.6, but get complex w/ and
2. in strict mode, any expansion of a unknown property into a string
would throw a BuildException
3. But there would be a non-throwing expansion method for code that
explicitly wanted to not fail on missing strings in their .
4. , and a few others would be modified to use the new
non throwing expansion mechanism.
The problem with this is that while
${undefined} would work as intended,
would always throw an exception.
The only fix there would be a new datatype NonvalidatingString() that
would expand properties but not bail.
Would that be enough? Would it work and be usable?
What about just displaying a warning "Use of undefined property foo at
line xxx" instead of failing ?
I suppose the problem was that undefined properties were just ignored,
and you had a hard time debugging this ( I had similar problems many
times ).
you can get those messages if you crank up the verbosity, but you still
need to go through the lines and look at them. I suppose if we had a
better listener model then I could run a listener to filter for the
relevant message topic and highlight them.
I would preffer a warning for undefined properties outside echo/fail
instead of the option to fail - since in the second case it may fail in
too many build.xml files, forcing people to just disable it.
I'd have the default of non-strict; fail-on-undefined would be an option
people could turn on for better diagnostics.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Ant 2.0
Steve Loughran wrote:
I know Ant2.0-the-rewrite is essentially dead (and essentially obsolete
through evolution in the codebase), but I still think we ought to
consider using the name as and when the time is appropriate. If we add
enough interesting stuff to 1.7, it could be the time.
Please, not again :-)
One thing that was voted on (positively, I recall), way way back in
time, was for Ant2.0 to fail on undefined properties.
Having just struggled with a build file refactor that introduced the
problem, a problem I only dealt with by resorting to IntelliJ's
property-aware ant file editor, I am starting to think the
fail-on-undefined property mechanism is good.
But at the same time, those echo statements with undefined properties
are ubiquitous, and they need to stay in. And we need the option of
turning strict property evaluation off or on.
My preferred way to do this would be to
1. either or both of
a new command line option,
a new property to set.
to turn strict property evaluation on.
The nice thing about these two is that they can be applied to existing
files. The property set tactic would let you use build.properties to set
the flag, and enable inline in projects that will still work in ant 1.6,
but get complex w/ and
2. in strict mode, any expansion of a unknown property into a string
would throw a BuildException
3. But there would be a non-throwing expansion method for code that
explicitly wanted to not fail on missing strings in their .
4. , and a few others would be modified to use the new non
throwing expansion mechanism.
The problem with this is that while
${undefined} would work as intended,
would always throw an exception.
The only fix there would be a new datatype NonvalidatingString() that
would expand properties but not bail.
Would that be enough? Would it work and be usable?
What about just displaying a warning "Use of undefined property foo at
line xxx" instead of failing ?
I suppose the problem was that undefined properties were just ignored,
and you had a hard time debugging this ( I had similar problems many
times ).
I would preffer a warning for undefined properties outside echo/fail
instead of the option to fail - since in the second case it may fail in
too many build.xml files, forcing people to just disable it.
Costin
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
