Jose Alberto Fernandez wrote:
...
Is there anything missing in macrodef that does not allow you using it?
Why, as you say, are you using the wrong strategy to solve your problem?
Because I've realized this just some days ago, mostly on this thread :-)
...
To tell you the truth, I haven't found in m
> From: Nicola Ken Barozzi [mailto:[EMAIL PROTECTED]
>
> Dominique Devienne wrote:
>
> >>From: Nicola Ken Barozzi [mailto:[EMAIL PROTECTED]
> >>Jose Alberto Fernandez wrote:
> ...
> >>>All this restriction in OO inheritance are there to limit
> developers
> >>>capability of writing spaguetti.
On Fri, 4 Jun 2004, Jose Alberto Fernandez <[EMAIL PROTECTED]>
wrote:
>> From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
>>
>> On Fri, 4 Jun 2004, Dominique Devienne <[EMAIL PROTECTED]> wrote:
>>
>> > This allows to bypass the target override, and thus bypass
>> > whatever the overridden target d
Dominique Devienne wrote:
From: Nicola Ken Barozzi [mailto:[EMAIL PROTECTED]
Jose Alberto Fernandez wrote:
...
All this restriction in OO inheritance are there to limit
developers capability of writing spaguetti. We still do, but...
Import overriding is not about OO inheritance, it's about target
d
> From: Nicola Ken Barozzi [mailto:[EMAIL PROTECTED]
> Jose Alberto Fernandez wrote:
> > Looks like spaguetti buildfiles to me.
> >
> > No ofence, but if the build have this kinds of fragile
> > dependencies, will anyone else understan what is going on
> > 6 month from now? That is what is wrong wi
Jose Alberto Fernandez wrote:
Looks like spaguetti buildfiles to me.
No ofence, but if the build have this kinds of fragile
dependencies, will anyone else understan what is going on
6 month from now? That is what is wrong with spaguetti code.
All this restriction in OO inheritance are there to limi
> -Original Message-
> From: Dominique Devienne [mailto:[EMAIL PROTECTED]
> Sent: 04 June 2004 19:26
> To: 'Ant Developers List'
> Subject: RE: Alias names for imported targets
>
>
> > From: Jose Alberto Fernandez [mailto:[EMAIL PROTECTED]
>
writing spaguetti. We still do, but...
Jose Alberto
> -Original Message-
> From: Nicola Ken Barozzi [mailto:[EMAIL PROTECTED]
> Sent: 04 June 2004 17:47
> To: [EMAIL PROTECTED]
> Subject: Re: Alias names for imported targets
>
>
> Dominique Devienne wrote:
> From: Jose Alberto Fernandez [mailto:[EMAIL PROTECTED]
> > From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
> > On Fri, 4 Jun 2004, Dominique Devienne <[EMAIL PROTECTED]> wrote:
> > > This allows to bypass the target override, and thus bypass whatever
> > > the overridden target does.
> >
> > Right
> From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
>
> On Fri, 4 Jun 2004, Dominique Devienne <[EMAIL PROTECTED]> wrote:
>
> > This allows to bypass the target override, and thus bypass whatever
> > the overridden target does.
>
> Right. But I already can bypass it if the target is
> overridde
Nicola Ken Barozzi wrote:...
task->target
--
Nicola Ken Barozzi [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
-
--
Dominique Devienne wrote:
From: Nicola Ken Barozzi [mailto:[EMAIL PROTECTED]
I've looked into the code (gosh, I still remember part of it :-)
The following path is OTOMH, without even compiling, it should be a start.
Implementing this is not the issue...
I know, I haven't replied to /your/ mail, b
> From: Erik Hatcher [mailto:[EMAIL PROTECTED]
>
> pasted from my original message on this:
>
> imported.xml
>
>
>
>
> build.xml
>
>
>
>
>
> Doesn't work, since some-target is not overridden.
>
> --
> It would be nice if imported.some-target existed
> From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
>
> I don't have a real world use-case, granted, my major reason is
> consistency - I want to be able to write depends="foo.bar" and not
> care whether it has been overridden or not.
Yeah, that's the part I don't like. Beside the target that actual
> From: Nicola Ken Barozzi [mailto:[EMAIL PROTECTED]
> I've looked into the code (gosh, I still remember part of it :-)
> The following path is OTOMH, without even compiling, it should be a start.
Implementing this is not the issue... --DD
-
On Fri, 4 Jun 2004, Dominique Devienne <[EMAIL PROTECTED]> wrote:
> This allows to bypass the target override, and thus bypass whatever
> the overridden target does.
Right. But I already can bypass it if the target is overridden since
I get the aliased name then. If this type of bypassing is wr
Stefan Bodewig wrote:
Hi,
Erik already brought that up. Target foo imported from project named
bar is known as "foo" in my build file unless I override it (in which
case it becomes "bar.foo". I'd like to have the alias name "bar.foo"
available even if I don't override it.
I haven't looked into th
On Jun 4, 2004, at 10:19 AM, Dominique Devienne wrote:
From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
Erik already brought that up. Target foo imported from project named
bar is known as "foo" in my build file unless I override it (in which
case it becomes "bar.foo". I'd like to have the alias na
> From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
> Erik already brought that up. Target foo imported from project named
> bar is known as "foo" in my build file unless I override it (in which
> case it becomes "bar.foo". I'd like to have the alias name "bar.foo"
> available even if I don't overri
I would *love* for this to be in 1.6.2
Alas, I've no time in the near future to look into it myself though,
sorry.
Erik
On Jun 4, 2004, at 8:13 AM, Stefan Bodewig wrote:
Hi,
Erik already brought that up. Target foo imported from project named
bar is known as "foo" in my build file un
Hi,
Erik already brought that up. Target foo imported from project named
bar is known as "foo" in my build file unless I override it (in which
case it becomes "bar.foo". I'd like to have the alias name "bar.foo"
available even if I don't override it.
I haven't looked into the code yet, but are
21 matches
Mail list logo
