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
On 10/17/06, Stefan Bodewig [EMAIL PROTECTED] wrote:
On Mon, 16 Oct 2006, Peter Reilly [EMAIL PROTECTED] wrote:
what do other people think?
I'm with Steve here. We need a way to get around broken build files
of projects you want to build but don't own.
I don't care much whether it is a
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
On 10/17/06, Dominique Devienne [EMAIL PROTECTED] 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
[...], a copy of the UE will be executed and the real object [...]
I guess this is where the difference really is. The implementation
on how the 'static' reference is resolve is now safer, yet at the user
level, the behavior remains the same, with just a new warning thrown
in. I wanted us to
I think some kind of property ant.policy.references.inline or something
could be set to turn on old behaviour
We've somehow never done it, but maybe we should have a version
attribute on project, and increment it whenever we introduce a BC
breaking change?
I'm not sure it's practical to
On 10/16/06, Dominique Devienne [EMAIL PROTECTED] wrote:
I think some kind of property ant.policy.references.inline or something
could be set to turn on old behaviour
We've somehow never done it, but maybe we should have a version
attribute on project, and increment it whenever we introduce a
WARNING: reference y has not been set, attempting to resolve
[echo] y is C:\Documents and Settings\reilly\learning\a\refs\build.xml
I really think we should break BC here, with a good error message.
Keeping the old behavior would re-open the bug about the
not-defined-at-runtime ref being
On 10/16/06, Dominique Devienne [EMAIL PROTECTED] wrote:
WARNING: reference y has not been set, attempting to resolve
[echo] y is C:\Documents and Settings\reilly\learning\a\refs\build.xml
I really think we should break BC here, with a good error message.
Keeping the old behavior would
Hi Dominique,
this sounds like a good idea.
Regards,
Antoine
Original-Nachricht
Datum: Mon, 16 Oct 2006 09:58:58 -0500
Von: Dominique Devienne [EMAIL PROTECTED]
An: Ant Developers List dev@ant.apache.org
Betreff: Re: references: backwards compatibility
WARNING: reference y
Peter Reilly wrote:
On 10/16/06, Dominique Devienne [EMAIL PROTECTED] wrote:
WARNING: reference y has not been set, attempting to resolve
[echo] y is C:\Documents and
Settings\reilly\learning\a\refs\build.xml
I really think we should break BC here, with a good error message.
Keeping
On Mon, 16 Oct 2006, Peter Reilly [EMAIL PROTECTED] wrote:
what do other people think?
I'm with Steve here. We need a way to get around broken build files
of projects you want to build but don't own.
I don't care much whether it is a property (would be in line with
other things we've
--- Stefan Bodewig [EMAIL PROTECTED] wrote:
On Mon, 11 Apr 2005, Matt Benson
[EMAIL PROTECTED] wrote:
Ever noticed that every Ant type that supports the
id/refid pattern must include a load of custom
code?
Why? Wouldn't it be possible in UE to check all
DataType subclass elements
On Mon, 11 Apr 2005, Matt Benson [EMAIL PROTECTED] wrote:
Ever noticed that every Ant type that supports the
id/refid pattern must include a load of custom code?
Why? Wouldn't it be possible in UE to check all
DataType subclass elements for refid, validate no
other
On Mon, 11 Apr 2005, Dominique Devienne [EMAIL PROTECTED] wrote:
So on second thought, it sounds doable. The only possible break of
BC I can foresee ATM would be for custom types, outside of Ant,
which broke the unwritten rule that no attributes/elements are
allowed once one uses
Matt Benson wrote:
Ha, I think we've been stonewalled. What we're
talking about is great for add* methods, but I think
we're out of luck for create* methods. Although I
never use these anymore either. Seems kind of bad to
say refid works on all datatypes automatically,
unless you use createXXX
--- Conor MacNeill [EMAIL PROTECTED] wrote:
I support moving reference processing into the core.
This is how mutant
worked. It is certainly a core responsibility.
It should only be done for addXXX methods. By the
core-task contract
those are the elements for which the task has given
Matt Benson wrote:
So the rule becomes, when writing a custom type, IF
you extend DataType, and IF those who program to your
custom type only use addXXX and/or add(Type), then the
refid attribute will be handled for you
automatically. That's all well and good, but
basically I don't see what it
From: Matt Benson [mailto:[EMAIL PROTECTED]
Ever noticed that every Ant type that supports the
id/refid pattern must include a load of custom code?
Why? Wouldn't it be possible in UE to check all
DataType subclass elements for refid, validate no
other attributes/elements/nested text, and
Hmm, from all your comments it seems you have pointed
out that the best solution would be for types to have
no knowledge whatsoever of refids. Of course this is
not possible under the gaze of the BC monster. We
could always start the mythological Ant 2 after 1.7 to
apply the learning of the past
From: Matt Benson [mailto:[EMAIL PROTECTED]
Hmm, from all your comments it seems you have pointed
out that the best solution would be for types to have
no knowledge whatsoever of refids.
True.
Of course this is
not possible under the gaze of the BC monster. We
could always start the
Ha, I think we've been stonewalled. What we're
talking about is great for add* methods, but I think
we're out of luck for create* methods. Although I
never use these anymore either. Seems kind of bad to
say refid works on all datatypes automatically,
unless you use createXXX methods... :( I
22 matches
Mail list logo
