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
My test code broke this am, since the update.
The cause? I was not explicitly depending on something that had needed
run.classpath defined, but the automatic-reference definition stuff had
been letting me get away with a (defective) build file.
I did fix it, but wasted some time before decid
16 matches
Mail list logo
