DO NOT REPLY [Bug 28444] - Import: Target Handling Bug

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

Re: [Bug 28444] - Import: Target Handling Bug

On Fri, 13 May 2005, Jose Alberto Fernandez <[EMAIL PROTECTED]> wrote: > We could generate something like: > > > > and then you are able to say: > > > > The target "imported.compile:depends" should be generated by > . Looks do-able and would address Steve's need as well. Stefan --

Re: [Bug 28444] - Import: Target Handling Bug

On Fri, 13 May 2005, Jose Alberto Fernandez <[EMAIL PROTECTED]> wrote: > Just to put closure in my list of peeves about , > I really think we need a way to define "private" targets. +1 Stefan - To unsubscribe, e-mail: [EMAIL PR

Re: [Bug 28444] - Import: Target Handling Bug

Rather than having a specific element, could this not be achieved via a naming convention such as "-target-name" (the leading "-" actually makes the target uninvocable from the command line anyway and therefore pretty good and private from the CLI point-of-view)? Or even a new attribute on target

Re: [Bug 28444] - Import: Target Handling Bug

Jose Alberto Fernandez wrote: Just to put closure in my list of peeves about , I really think we need a way to define "private" targets. +1, one should be able to write an importable build file that has some exported targets - but internally uses targets that do not get overwritten accidently. P

RE: [Bug 28444] - Import: Target Handling Bug

Just to put closure in my list of peeves about , I really think we need a way to define "private" targets. Now, for this to work properly, you need: 1) A way to mark a target as private. 2) private targets must be ignored by targets of the same names on other points in the hierarchy. 3) Depends

Re: [Bug 28444] - Import: Target Handling Bug

Anyone consider: ... Nicola Ken Barozzi wrote: Jose Alberto Fernandez wrote: Going to the old discussions in how to approach this issues, the thing that bother me most, is that in order to get access to an imported target I need to know the name given to the project on the file that did the impor

Re: [Bug 28444] - Import: Target Handling Bug

Evan Easton wrote: ... Valid point. But isn't the depends list of an imported target something that you'd really like to not muck with in the interests of encapsulation? I agree that it would be really nice to be able to insert into or at the end of the overridden target's dependencies (a la as

Re: DO NOT REPLY [Bug 28444] - Import: Target Handling Bug

Jose Alberto Fernandez wrote: From: Peter Reilly [mailto:[EMAIL PROTECTED] Matt Benson wrote: I can't imagine a scenario where BC would be compromised, but I'd be glad for an example. -Matt I was thinking of the example with multiple import files with the same projectname/targetname

Re: [Bug 28444] - Import: Target Handling Bug

Anyone consider: ... Nicola Ken Barozzi wrote: Jose Alberto Fernandez wrote: Going to the old discussions in how to approach this issues, the thing that bother me most, is that in order to get access to an imported target I need to know the name given to the project on the file that did the impor

Re: [Bug 28444] - Import: Target Handling Bug

Nicola Ken Barozzi wrote: Steve Loughran wrote: Phil Weighill-Smith wrote: I missed the beginning of this thread but just want to say that I personally think that import is the best feature in Ant today (apart from Ant's being in the first place, that is)! I find it hard to work with in a big pr

Re: [Bug 28444] - Import: Target Handling Bug

Stefan Bodewig wrote: On Fri, 13 May 2005, Jose Alberto Fernandez <[EMAIL PROTECTED]> wrote: Well, alternatively you could overide "setup": Sure, we can certainly play fetch-me-a-rock here. I just need to come up with a more complex scenario and there will be no solution for it in which I

RE: DO NOT REPLY [Bug 28444] - Import: Target Handling Bug

> From: Peter Reilly [mailto:[EMAIL PROTECTED] > > Matt Benson wrote: > > >I can't imagine a scenario where BC would be > >compromised, but I'd be glad for an example. > > > >-Matt > > > > > > > I was thinking of the example with multiple import files with > the same projectname/targetname. >

Re: DO NOT REPLY [Bug 28444] - Import: Target Handling Bug

Matt Benson wrote: I can't imagine a scenario where BC would be compromised, but I'd be glad for an example. -Matt I was thinking of the example with multiple import files with the same projectname/targetname. example: a.xml a.xml b.xml b.xml c.xml c.xml build.xml In this case, ant 1.

Re: [Bug 28444] - Import: Target Handling Bug

On Fri, 13 May 2005, Peter Reilly <[EMAIL PROTECTED]> wrote: > Stefan Bodewig wrote: >>Do we really need to create a complete clone? Can't we achieve the >>same with a more lazy approach? >> >>Turning Matt's idea around: > > I do not see what that will buy us much in terms of efficeny. Frankly,

RE: [Bug 28444] - Import: Target Handling Bug

> From: Stefan Bodewig [mailto:[EMAIL PROTECTED] > > On Fri, 13 May 2005, Jose Alberto Fernandez > <[EMAIL PROTECTED]> wrote: > > > Well, alternatively you could overide "setup": > > Sure, we can certainly play fetch-me-a-rock here. I just > need to come up with a more complex scenario and t

Re: [Bug 28444] - Import: Target Handling Bug

Stefan Bodewig wrote: On Thu, 12 May 2005, Peter Reilly <[EMAIL PROTECTED]> wrote: The target gets renamed if there another target of the same name, but not otherwise - how can one write a proper reusable import file using the rename feature in this case? I'm strongly +1 for at least provid

Re: [Bug 28444] - Import: Target Handling Bug

On Fri, 13 May 2005, Jose Alberto Fernandez <[EMAIL PROTECTED]> wrote: > Well, alternatively you could overide "setup": Sure, we can certainly play fetch-me-a-rock here. I just need to come up with a more complex scenario and there will be no solution for it in which I didn't have to duplicate (

RE: [Bug 28444] - Import: Target Handling Bug

> From: Stefan Bodewig [mailto:[EMAIL PROTECTED] > > On Fri, 13 May 2005, Jose Alberto Fernandez > <[EMAIL PROTECTED]> wrote: > >> From: Stefan Bodewig [mailto:[EMAIL PROTECTED] > > >> Another related problem I have is that you can't add > >> something to the beginning of a target easily. You

Re: [Bug 28444] - Import: Target Handling Bug

Jose Alberto Fernandez wrote: Going to the old discussions in how to approach this issues, the thing that bother me most, is that in order to get access to an imported target I need to know the name given to the project on the file that did the import. This in my opinion contradicts the hidding rul

Re: [Bug 28444] - Import: Target Handling Bug

On Fri, 13 May 2005, Jose Alberto Fernandez <[EMAIL PROTECTED]> wrote: >> From: Stefan Bodewig [mailto:[EMAIL PROTECTED] >> Another related problem I have is that you can't add >> something to the beginning of a target easily. You can add >> someting to the end of "foo" by writing your own "fo

RE: [Bug 28444] - Import: Target Handling Bug

> From: Phil Weighill Smith [mailto:[EMAIL PROTECTED] > > On Fri, 2005-05-13 at 11:38 +0100, Jose Alberto Fernandez wrote: > > I would advocate to allow the importer the specify the > aliasing name > > it wants to use for the imported things, so one has something like: > > > > foo.xml > > > >

RE: [Bug 28444] - Import: Target Handling Bug

On Fri, 2005-05-13 at 11:38 +0100, Jose Alberto Fernandez wrote: > I would advocate to allow the importer the specify the aliasing name > it > wants to use for the imported things, so one has something like: > > foo.xml > > ... > > > bar.xml > > > ... > +1 to the 'as=""'. Would we s

RE: [Bug 28444] - Import: Target Handling Bug

> From: Stefan Bodewig [mailto:[EMAIL PROTECTED] > Sent: 13 May 2005 11:10 > To: dev@ant.apache.org > Subject: Re: [Bug 28444] - Import: Target Handling Bug > > > Another related problem I have is that you can't add > something to the beginning of a target easily

Re: [Bug 28444] - Import: Target Handling Bug

On Fri, 2005-05-13 at 10:25 +0100, Steve Loughran wrote: > -when you override a target, you dont get access to its dependents. > Workaround: many pseudo-targets that only model dependencies. In fact we have "real" targets that don't have dependencies and it is these that we override. These are al

RE: [Bug 28444] - Import: Target Handling Bug

[EMAIL PROTECTED] > Sent: 12 May 2005 20:35 > To: dev@ant.apache.org > Subject: Re: [Bug 28444] - Import: Target Handling Bug > > > On Thu, 12 May 2005, Peter Reilly <[EMAIL PROTECTED]> wrote: > > > The target gets renamed if there another target of the same >

Re: [Bug 28444] - Import: Target Handling Bug

On Fri, 13 May 2005, Nicola Ken Barozzi <[EMAIL PROTECTED]> wrote: > Stefan Bodewig wrote: >> On Thu, 12 May 2005, Dominique Devienne <[EMAIL PROTECTED]> >> wrote: > ... >>>And targets from different imported build files that conflict >>>(multiple inheritance) should raise an error unless explicitl

Re: [Bug 28444] - Import: Target Handling Bug

On Fri, 13 May 2005, Phil Weighill Smith <[EMAIL PROTECTED]> wrote: > On Fri, 2005-05-13 at 09:00 +0200, Stefan Bodewig wrote: > >> > But say the importER explicitly depends on bar.foo . Isn't this >> > still going to pollute the log in the opposite way my >> > implementation would? :) i.e. >> >

Re: [Bug 28444] - Import: Target Handling Bug

On Fri, 13 May 2005, Steve Loughran <[EMAIL PROTECTED]> wrote: > Phil Weighill-Smith wrote: >> I missed the beginning of this thread but just want to say that I >> personally think that import is the best feature in Ant today >> (apart from Ant's being in the first place, that is)! > > I find it h

Re: [Bug 28444] - Import: Target Handling Bug

Steve Loughran wrote: Phil Weighill-Smith wrote: I missed the beginning of this thread but just want to say that I personally think that import is the best feature in Ant today (apart from Ant's being in the first place, that is)! I find it hard to work with in a big project. problems -risk of ad

Re: [Bug 28444] - Import: Target Handling Bug

Phil Weighill-Smith wrote: I missed the beginning of this thread but just want to say that I personally think that import is the best feature in Ant today (apart from Ant's being in the first place, that is)! I find it hard to work with in a big project. problems -risk of adding a new target in an

Re: [Bug 28444] - Import: Target Handling Bug

On Fri, 2005-05-13 at 09:00 +0200, Stefan Bodewig wrote: > > But say the importER explicitly depends on bar.foo . Isn't this > > still going to pollute the log in the opposite way my implementation > > would? :) i.e. > > > > [foo]: > > > > [bar.foo]: > > Yes. But this is less likely than havi

Re: [Bug 28444] - Import: Target Handling Bug

On Thu, 12 May 2005, Matt Benson <[EMAIL PROTECTED]> wrote: > You confused me with the "later." I wasn't sure how the target overriding was implemented so wanted to be save. > Our local targets are known before we actually execute a top-level > (target "") import, right? Probably. If you say s

Re: [Bug 28444] - Import: Target Handling Bug

Stefan Bodewig wrote: On Thu, 12 May 2005, Dominique Devienne <[EMAIL PROTECTED]> wrote: ... And targets from different imported build files that conflict (multiple inheritance) should raise an error unless explicitly imported "as" given by the importer (not the name of the imported project as is t

RE: [Bug 28444] - Import: Target Handling Bug

Sent: Thu 12/05/2005 21:43 To: Ant Developers List Cc: Subject: Re: [Bug 28444] - Import: Target Handling Bug --- Stefan Bodewig <[EMAIL PROTECTED]> wrote: [SNIP] > Turning Matt's idea around: > &g

Re: [Bug 28444] - Import: Target Handling Bug

--- Stefan Bodewig <[EMAIL PROTECTED]> wrote: [SNIP] > Turning Matt's idea around: > > (1) Target "foo" is in project "bar". > (2a) There already is a target "foo" from the file > that imported > "bar", use the current code, we are ready, > "bar.foo" is there. > (2b) There is no other target

Re: [Bug 28444] - Import: Target Handling Bug

On Thu, 12 May 2005, Dominique Devienne <[EMAIL PROTECTED]> wrote: > The imported build names should never appear in the importer, we > should have an explicit override attribute (or something) that tells > Ant the target is meant to override a target in an imported build > (which fails the build

Re: [Bug 28444] - Import: Target Handling Bug

On Thu, 12 May 2005, Peter Reilly <[EMAIL PROTECTED]> wrote: > The target gets renamed if there another target of the same name, > but not otherwise - how can one write a proper reusable import file > using the rename feature in this case? I'm strongly +1 for at least providing renamed aliases fo

Re: Bugzilla or dev-list (was Re: [Bug 28444] - Import: Target Handling Bug)

--- Stefan Bodewig <[EMAIL PROTECTED]> wrote: > On Thu, 12 May 2005, Matt Benson > <[EMAIL PROTECTED]> wrote: > > > Here's my comment from the bug since Stefan wants > to > > be on-list: :) > > I'll go back to the original thread in a minute, > just wanted to > explain why I asked Peter to disc

Bugzilla or dev-list (was Re: [Bug 28444] - Import: Target Handling Bug)

On Thu, 12 May 2005, Matt Benson <[EMAIL PROTECTED]> wrote: > Here's my comment from the bug since Stefan wants to > be on-list: :) I'll go back to the original thread in a minute, just wanted to explain why I asked Peter to discuss it on the list. When I see bugzilla reports that look as if so

Re: DO NOT REPLY [Bug 28444] - Import: Target Handling Bug

(RE depend vs. clone:) --- Peter Reilly <[EMAIL PROTECTED]> wrote: > The problem with this is that the output will change > to . for all imported > targets - i.e. it will expose the implementation a > little too much. > > Also the overriding behavior needs to be implements > in the > same way as i

Re: DO NOT REPLY [Bug 28444] - Import: Target Handling Bug

The problem with this is that the output will change to . for all imported targets - i.e. it will expose the implementation a little too much. Also the overriding behavior needs to be implements in the same way as is currently done, otherwise there would be BC issues. Peter [EMAIL PROTECTED] wrote:

Re: [Bug 28444] - Import: Target Handling Bug

> I never liked the target renaming stuff - it seems a bit strange. > Be that as it may, the current behaviour is a bit silly - i.e. inconsistent. > The target gets renamed if there another target of the same name, but > not otherwise - how can one write a proper reusable import file using the > re

DO NOT REPLY [Bug 28444] - Import: Target Handling Bug

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

Re: [Bug 28444] - Import: Target Handling Bug

Here's my comment from the bug since Stefan wants to be on-list: :) I also support fixing this. However, instead of cloning the entire target, couldn't we: a) unconditionally rename the imported target b) if the target has NOT been overridden, create a new target that depends on the imported t

DO NOT REPLY [Bug 28444] - Import: Target Handling Bug

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

Re: [Bug 28444] - Import: Target Handling Bug

Stefan Bodewig wrote: Be that as it may, the current behaviour is a bit silly - i.e. inconsistent. big +1 But we should discuss it here instead of in bugzilla - nobody's going to follow it there. I know that I don't. No problem. The bug is : http://issues.apache.org/bugzilla/show_bug.cgi?i

Re: DO NOT REPLY [Bug 28444] - Import: Target Handling Bug

On Thu, 12 May 2005, <[EMAIL PROTECTED]> wrote: > Additional Comments From [EMAIL PROTECTED] > Be that as it may, the current behaviour is a bit silly - > i.e. inconsistent. big +1 But we should discuss it here instead of in bugzilla - nobody's going to follow it there. I know that I don't. S

DO NOT REPLY [Bug 28444] - Import: Target Handling Bug

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 28444] - Import: Target Handling Bug

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 28444] - Import: Target Handling Bug

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 28444] - Import: Target Handling Bug

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 28444] - Import: Target Handling Bug

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 28444] - Import: Target Handling Bug

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 28444] - Import: Target Handling Bug

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 28444] - Import: Target Handling Bug

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 28444] - Import: Target Handling Bug

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu