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
On Tue, 17 October, 2006 5:24 pm, Dominique Devienne wrote:
>> > BC is important to me, but when keeping BC means breaking my least
>> > surprises motto, then BC is not my friend any more ;-) --DD
>>
>> I am afraid that ant has a lot of surprises!
>
> And this is bad. That's why Ant is difficult to
[...], 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
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
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 ma
Peter Reilly wrote:
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
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
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 introd
I would make it a non-failing warning for ant1.7, maybe an error in 1.8.
I can see where you are coming from, but I disagree on accepting the
old build files, or at least not without a --keep-old-broken-behavior
switch on the command line, instead of yet another magic property.
--DD
--
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.
Keepi
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"
Betreff: Re: references: backwards compatibility
> &
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 wou
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 us
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 , and increment it whenever we introduce a BC
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 , and increment it whenever we introduce a BC
breaking change?
I'm not sure it's practical to provide both t
--- 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 subcl
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 refdid=
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 attributes/element
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 g
--- 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 g
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
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 m
> 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 star
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]
>
> 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
25 matches
Mail list logo
