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

[bugzilla]

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_bug.cgi?id=28444


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED




--- Additional Comments From [EMAIL PROTECTED]  2005-05-17 12:54 ---
Fix checked into cvs HEAD.
The  "ant -f C.xml x" test will now work.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

[Stefan Bodewig]

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

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

[Stefan Bodewig]

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 PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

[Phil Weighill Smith]

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 that indicates that it is "private"?

Phil :n.

On Fri, 2005-05-13 at 17:18 +0100, Peter Reilly wrote:
> 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.
> 
> Peter
> 
> >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 on a private target must be resolved by the correct instance
> >of the target.
> >
> >So lets assume the following syntax:
> >
> > ...
> >
> >foo.xml
> >
> >   >message="compiling"/>
> >
> >
> >bar.xml
> >
> >  
> >   >message="building"/>
> >  
> >
> >
> >baz.xml
> >
> >  
> >  
> >
> >
> >ant compile
> >  prepare compile
> >  compiling
> >
> >ant build
> >  prepare build
> >  building
> >
> >Here: 
> >foo.xml is like an abstract project which does not define "setup";
> >bar.xml's setup is private to bar1 and will not be used by the
> >dependency in foo1
> >baz.xml overrides (defines in this case) the setup target used in foo1
> >but not the one in bar1.
> >
> >The rewriting rules are a bit tricky, because for every private target
> >you need to use a new "private name" for it, and change all the
> >occurencies
> >in dependencies on that file of the name, for the new name.
> >
> >Seems actually doable.
> >
> >Jose Alberto
> >
> >
> >
> >-
> >To unsubscribe, e-mail: [EMAIL PROTECTED]
> >For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> >
> >  
> >
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

[Peter Reilly]

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.
Peter
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 on a private target must be resolved by the correct instance
of the target.
So lets assume the following syntax:
...
foo.xml

 

bar.xml

 
 
 

baz.xml

 
 

ant compile
 prepare compile
 compiling
ant build
 prepare build
 building
Here: 
foo.xml is like an abstract project which does not define "setup";
bar.xml's setup is private to bar1 and will not be used by the
dependency in foo1
baz.xml overrides (defines in this case) the setup target used in foo1
but not the one in bar1.

The rewriting rules are a bit tricky, because for every private target
you need to use a new "private name" for it, and change all the
occurencies
in dependencies on that file of the name, for the new name.
Seems actually doable.
Jose Alberto

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

[Jose Alberto Fernandez]

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 on a private target must be resolved by the correct instance
of the target.

So lets assume the following syntax:

 ...

foo.xml

  


bar.xml

  
  
  


baz.xml

  
  


ant compile
  prepare compile
  compiling

ant build
  prepare build
  building

Here: 
foo.xml is like an abstract project which does not define "setup";
bar.xml's setup is private to bar1 and will not be used by the
dependency in foo1
baz.xml overrides (defines in this case) the setup target used in foo1
but not the one in bar1.

The rewriting rules are a bit tricky, because for every private target
you need to use a new "private name" for it, and change all the
occurencies
in dependencies on that file of the name, for the new name.

Seems actually doable.

Jose Alberto



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

[Evan Easton]

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 import.
This in my opinion contradicts the hidding rules of OO programming.
I should not need to know about the internals of an imported object.
It also means that I have to coordinate all the files I may directly
or indirectly import so that there is no project name clashes.

You could make the argument that the name isn't really an internal.  
It's just an alias to reference the project since using the filename 
might not be desirable.  Java and some other languages base the name of 
a class or module on the file or require the two to be the same.  But 
what about C++, and probably others.  You can declare whatever classes 
you want in a .h file with any name and yet you still expect the user to 
include some "file name" (e.g. ) and then use classes defined 
inside that file which may hve difference names (e.g. stringbuf, 
ostringstream,...).

Some of the information defined inside the imported build file has to be 
accessible to the outside.  It seems reasonable that, just like the 
target names, macro, presets, tasks, selectors, properties,  the 
project name could be one more piece of useful information.  You just 
now have to be careful not to rename the project if others might be 
importing your build filejust like any resource, in any 
imported/included file, is virtually any language.

Evan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

[Evan Easton]

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 aspect oriented 
languages), but I think I could contrive cases where this 
unintentionally breaks the functionality of the overridden target.
I'm not saying it shouldn't be supported, but I think we are sill 
grappling with a basic OO-link inheritance problem that we need to 
address before diving into aspect oriented constructs which, while 
very powerful, seem to create lots of issues unless you really know 
what you're doing.
BTW,
While I don't think ant should become a polymorphic OO language, I do 
think that this override bug should be addressed by following 
conventions present in most OO languages. This is mostly because I'd 
like to not have to remember yet another oddball inheritance/override 
model and with a pure virtual, polymorphic model I'd know exactly what 
I'm doing.  Of course, since I've been coding for 20 years, I'm not 
really sure that this make things easier on newbies.  Plus there's 
the whole multiple inheritance debate to have all over again.
Evan

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

[Peter Reilly]

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.

example:
a.xml a.xml
b.xml b.xml
c.xml c.xml
build.xml

  
  
  

In this case, ant 1.6.x (and my patch) will output.
ant t
 will output "a.xml"
ant p.t
 will output "c.xml"
   

Ok, your example confused me. What is p.t p is not imported, why would
we have a p.t target?
 

I am talking about the current ant (1.6.x) implemention of import.
If an imported file does not have a project name, it "inherits" the 
project name it
uses in the target name from the importing project.

Peter
I do not understand why you get different answers for "p.t" and "t" is
the same target on
the same project (is it not?).
Did you meant  on the imported? Then I see what you
are saying.
Although it is probably difficult to avoid given the fact that 
is an
executed task. But hey, more reason for adding 'as' since otherwise
there is no
way to disambiguate appart from changing the imported files. :-P
Jose Alberto
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

[Evan Easton]

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 import.
This in my opinion contradicts the hidding rules of OO programming.
I should not need to know about the internals of an imported object.
It also means that I have to coordinate all the files I may directly
or indirectly import so that there is no project name clashes.

You could make the argument that the name isn't really an internal.  
It's just an alias to reference the project since using the filename 
might not be desirable.  Java and some other languages base the name of 
a class or module on the file or require the two to be the same.  But 
what about C++, and probably others.  You can declare whatever classes 
you want in a .h file with any name and yet you still expect the user to 
include some "file name" (e.g. ) and then use classes defined 
inside that file which may hve difference names (e.g. stringbuf, 
ostringstream,...).

Some of the information defined inside the imported build file has to be 
accessible to the outside.  It seems reasonable that, just like the 
target names, macro, presets, tasks, selectors, properties,  the 
project name could be one more piece of useful information.  You just 
now have to be careful not to rename the project if others might be 
importing your build filejust like any resource, in any 
imported/included file, is virtually any language.

Evan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

[Steve Loughran]

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 project.
problems
-risk of adding a new target in an imported build file conflicting 
with one in the importer (i.e. lack of private scope)
 >
-when you override a target, you dont get access to its dependents. 
Workaround: many pseudo-targets that only model dependencies.

Could you please explain more? TIA
Imagine I have a base build file with a target "compile". If I overwrite 
it in a project, I need to manually redeclare all dependencies of the 
compile target

base
...
extension
...

That is, I need to know and declare the dependencies again. If I change 
the dependencies of the base target, all derived files need updating. 
What I want to say is

...

The workaround is pseudo targets

...
and then depend on the pre-compile target in derived build files
...

-once you have sub-projects importing ../../common.xml, they are no 
longer self contained, which makes it harder to work with outside the 
existing build tree.

I dont see any good solution for the latter.

The first and the last "problems" are in fact worksforme, as the import 
task is *intended* to pollute the project files that use it to be able 
to work as needed.
yes, but I dont always want to pollute project files with my inner 
workings.

In most cases, one would want to use ,  or  
instead of importing buildfiles with s, which should be used 
only to reuse and "extend" a base buildfile.
macrodef/presetdef defines standard actions; the base buildfile defines 
the standard process.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

[Evan Easton]

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 didn't have to duplicate (partial) depends lists or
introduce empty targets.
Stefan
 

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 aspect oriented languages), 
but I think I could contrive cases where this unintentionally breaks the 
functionality of the overridden target. 

I'm not saying it shouldn't be supported, but I think we are sill 
grappling with a basic OO-link inheritance problem that we need to 
address before diving into aspect oriented constructs which, while very 
powerful, seem to create lots of issues unless you really know what 
you're doing.

Evan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

[Jose Alberto Fernandez]

> 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.
> 
> example:
> a.xml a.xml
> b.xml b.xml
> c.xml c.xml
> build.xml
> 
>
>
>
> 
> 
> In this case, ant 1.6.x (and my patch) will output.
> 
> ant t
>   will output "a.xml"
> ant p.t
>   will output "c.xml"
> 

Ok, your example confused me. What is p.t p is not imported, why would
we have a p.t target?
I do not understand why you get different answers for "p.t" and "t" is
the same target on
the same project (is it not?).

Did you meant  on the imported? Then I see what you
are saying.
Although it is probably difficult to avoid given the fact that 
is an
executed task. But hey, more reason for adding 'as' since otherwise
there is no
way to disambiguate appart from changing the imported files. :-P

Jose Alberto

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

[Peter Reilly]

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.6.x (and my patch) will output.
ant t
 will output "a.xml"
ant p.t
 will output "c.xml"

Peter
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

[Stefan Bodewig]

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, neither do I.  I don't have a real problem with your cloning
approach either.

> However, there should be no need to replace the placeholder as the
> overridding targets are processed first.

Yes, Matt already told me that my memory was failing on me.

Stefan

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

[Jose Alberto Fernandez]

> 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 there will 
> be no solution for it in which I didn't have to duplicate 
> (partial) depends lists or introduce empty targets.
> 

In any case, I know what you mean. The difference that we have with
regular OO procedural languages is that we need to refer to the
dependencies
in the inheritance and we do not have a way to express that.
Although the notation bellow is wrong, what you would like is something
like:



I do not like ${depends-of:...} because it looks too much like something
evaluated dynamically,
which may be the case, but then people will want to be able to use
properties and that is a 
no-no for me.

We could generate something like:



and then you are able to say:



The target "imported.compile:depends" should be generated by .

This may duplicate the amount of targets, which may be not nice, but we
could have something
on  to request this depends targets. Something like:



This will add the additional targets "imported.compile:depends" and
"imported.build:depends".

What do you think? Too complicated?

Jose Alberto


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

[Peter Reilly]

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 providing renamed aliases for all
targets, independent on how we achieve that.
 

The fix will have a small overhead - the target object needs to be
cloned and given a a new name, whereas the current code just renames
the target object.
   

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:
(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 "foo" yet.  Create an empty placeholder
target "bar.foo" that depends on "foo".
If then later a target "foo" is found in the importing buildfile,
replace the placeholder "bar.foo" with the initial "foo" target.
 

I do not see what that will buy us much in terms of efficeny. However, 
there should be
no need to replace the placeholder as the overridding targets are 
processed first.


Wouldn't that work, stay backwards compatible and hide "bar." whenever
possible?
 

Yes.. I think so.
Peter
Stefan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

[Stefan Bodewig]

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 (partial) depends lists or
introduce empty targets.

Stefan

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

[Jose Alberto Fernandez]

> 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 can add 
> >> someting to the end of "foo" by writing your own "foo" that 
> >> depends on "imported.foo", but if you want to add something 
> >> at the start your imported build file has to be designed for 
> >> it.  Which means pseudo-targets that are used as interception 
> >> points only.
> >> 
> > 
> > Cant you write on the importing file:
> > 
> > 
> > 
> > ...
> 
> Not if I want to inject stuff between the targets 
> "imported.foo" depends on and "imported.foo" itself.
> 
> imported.xml
> 
> ,
> | 
> |   ...
> | 
> | 
> | 
> |   
> | 
> `
> 
> build.xml
> 
> ,
> | 
> |   
> | 
> `
> 
> how do I get the build sequence imported.setup, 
> generate-java-from-idl, compile without modifying 
> imported.xml and without access to the dependencies of "compile"?
> 
> Today I either add depends="setup" to 
> "generate-java-from-idl" and have to change that whenever the 
> depends list of "compile" changes or I introduce an empty 
> target to imported.xml, make "compile" depend on it (as the 
> last target in the list) and the override this empty target 
> with "generate-java-from-idl".
> 

Well, alternatively you could overide "setup":

  

Actually, one could argue that generate-java-from-idl is part of the
setup 
for "compile" in this context and hence that is the correct target to
override.

Jose Alberto

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

[Nicola Ken Barozzi]

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 rules of OO programming.
I should not need to know about the internals of an imported object.
It also means that I have to coordinate all the files I may directly
or indirectly import so that there is no project name clashes. 
Java imports packages that have to be unique based on a naming 
convention; AFAIK if package names are not unique, you have clashes.
Unfortunately now it's too late to reccomend a naming convention.

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:
...
  
Very nice, I like it.
--
Nicola Ken Barozzi   [EMAIL PROTECTED]
- verba volant, scripta manent -
   (discussions get forgotten, just code remains)
-
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

[Stefan Bodewig]

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 "foo" that 
>> depends on "imported.foo", but if you want to add something 
>> at the start your imported build file has to be designed for 
>> it.  Which means pseudo-targets that are used as interception 
>> points only.
>> 
> 
> Cant you write on the importing file:
> 
> 
> 
> ...

Not if I want to inject stuff between the targets "imported.foo"
depends on and "imported.foo" itself.

imported.xml

,
| 
|   ...
| 
| 
| 
|   
| 
`

build.xml

,
| 
|   
| 
`

how do I get the build sequence imported.setup,
generate-java-from-idl, compile without modifying imported.xml and
without access to the dependencies of "compile"?

Today I either add depends="setup" to "generate-java-from-idl" and
have to change that whenever the depends list of "compile" changes or
I introduce an empty target to imported.xml, make "compile" depend on
it (as the last target in the list) and the override this empty target
with "generate-java-from-idl".

Stefan

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

[Jose Alberto Fernandez]

> 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
> > 
> >   ...
> > 
> > 
> > bar.xml
> > 
> >   
> >   ...
> > 
> 
> +1 to the 'as=""'.
> 
> Would we still be able to reference "imp1.compile" as just 
> "compile" if the target has not been overridden in the 
> importing build script: I think this is very important to maintain.

Yes, you would have a "compile" target which is the realization of the
inheritance:

 

Or something like that, the question is what you get if there are
ambiguities due to multiple imports (you may get just the first one, or
an error)
unless you override and specify what you want them to do.

Jose Alberto

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

[Phil Weighill Smith]

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 still be able to reference "imp1.compile" as just "compile" if
the target has not been overridden in the importing build script: I
think this is very important to maintain.

Phil :n.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

[Jose Alberto Fernandez]

> 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.  You can add 
> someting to the end of "foo" by writing your own "foo" that 
> depends on "imported.foo", but if you want to add something 
> at the start your imported build file has to be designed for 
> it.  Which means pseudo-targets that are used as interception 
> points only.
> 

Cant you write on the importing file:



...

Or was that what you meant? Notice that the imported file does not
need to know about it.

Jose Alberto

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

[Phil Weighill Smith]

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 also useful, in large projects, when
you know you've made a change that doesn't require a complete dependency
build to be performed.







Again we find this useful as a developer may be updating (internal) code
in one subsystem only and this allows us to avoid a four or five minute
delay while Ant and Java work out exactly which classes need to be re-
built across the whole project. Clearly the developer directly uses "no
dependency" targets at their own risk as there could be dependencies
that really do need to be processed.

> -once you have sub-projects importing ../../common.xml, they are no 
> longer self contained, which makes it harder to work with outside the 
> existing build tree.

We address this by having a wrapper for (or alias to) ant that
specifically sets a property that points to the "common.xml"'s location
so as long as that location exists and has "common.xml" in it all is
fine.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

[Jose Alberto Fernandez]

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 rules of OO programming.
I should not need to know about the internals of an imported object.
It also means that I have to coordinate all the files I may directly
or indirectly import so that there is no project name clashes. 

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

  
  ...


baz.xml

  
  ...
  

  


The point being that the user of the imports is the one deciding how to
refer to
the targets in its own local file. For BC, is no 'as' attribute is
specified we
can use the imported project name.

At implementation, what we need to do is for every imported target,
rewrite their names
and add an empty target with the original name, if not already
overriden.

I think that is all that is necessary.

Jose Alberto

> -Original Message-
> From: Stefan Bodewig [mailto:[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 
> 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 for 
> all targets, independent on how we achieve that.
> 
> > The fix will have a small overhead - the target object needs to be 
> > cloned and given a a new name, whereas the current code 
> just renames 
> > the target object.
> 
> 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:
> 
> (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 "foo" yet.  Create an empty placeholder
>  target "bar.foo" that depends on "foo".
> 
>  If then later a target "foo" is found in the importing buildfile,
>  replace the placeholder "bar.foo" with the initial "foo" target.
> 
> Wouldn't that work, stay backwards compatible and hide "bar." 
> whenever possible?
> 
> Stefan
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

[Stefan Bodewig]

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 explicitly
>>>imported "as" given by the importer (not the name of the imported
>>>project as is the case now).
>> Can't we have this as an addition anyway?
> 
> Why?

To give the importer control over the prefix and make it a bit more
independent from the author of the imported file.  I may even want to
import to files coming from two different authors but having the same
project name.

Stefan

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

[Stefan Bodewig]

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.
>> > 
>> > [foo]:
>> > 
>> > [bar.foo]:
>> 
>> Yes.  But this is less likely than having the importer depend on
>> "foo" IMHO.  So in the normal case everything would look the same
>> as today and in border cases we'll get an additional empty target.
> 
> If I understand what you're saying correctly, you don't expect
> importer build scripts to depend explicitly on the renamed imported
> targets.

No.  I fully expect importers to do so now.  And if they do they must
have overridden the target themselves, so what Matt descibes doesn't
happen.

Let's take your example and add a target.

> I'd disagree: we commonly "augment" the standard targets like this:
> 
> standard.xml:
> 
> 
> ...
  
> 
> 
> build.xml:
> 
> 
> 
> 
> ...
> 

Today your build.xml can't use a target that depends on
"standard.new-target" as this target doesn't exist.

Peter's approach would create a copy of "new-target" with the name
"standard.new-target".

Matt's approach would implicitly add a new target

  

to build.xml (which also renames the "new-target" in standard.xml to
"standard.new-target").  Now if you run

$ ant new-target

the output will be

,
| standard.new-target:
| 
| new-target:
`

and you see that new-target has been imported from standard.

My approach would adds

  

to build.xml.  "ant new-target" still looks the same as it would if we
don't add a target at all.  But now if you use

$ ant standard.new-target

the output will be

,
| new-target:
| 
| standard.new-target:
`

So in either case you get to see an implementation detail - the empty
target that either Matt or I wanted to introduce.  I simply claimed
that Matt's case was more likely to happen than mine since you can't
depend on "standard.new-target" or invoke "ant standard.new-target" at
all today.

Stefan

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

[Stefan Bodewig]

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 hard to work with in a big project.
> 
> problems
> -risk of adding a new target in an imported build file conflicting
> with one in the importer (i.e. lack of private scope)

Does that really happen for you?

The workaround is to use ugly, likely to be unique target names - or
address the enhancement request this discussion came from and depend
on "imported.foo" for your newly introduced meant-to-be-private target
"foo".

> -when you override a target, you dont get access to its
> dependents. Workaround: many pseudo-targets that only model
> dependencies.

When you completely want to replace a target that is, true.

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 "foo" that depends on "imported.foo", but if
you want to add something at the start your imported build file has to
be designed for it.  Which means pseudo-targets that are used as
interception points only.

> -once you have sub-projects importing ../../common.xml, they are no
> longer self contained, which makes it harder to work with outside
> the existing build tree.

Once we can import URLs, you can have a solution for this, at least
for "network connected" development.

Stefan

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

[Nicola Ken Barozzi]

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 adding a new target in an imported build file conflicting with 
one in the importer (i.e. lack of private scope)
>
-when you override a target, you dont get access to its dependents. 
Workaround: many pseudo-targets that only model dependencies.
Could you please explain more? TIA
-once you have sub-projects importing ../../common.xml, they are no 
longer self contained, which makes it harder to work with outside the 
existing build tree.

I dont see any good solution for the latter.
The first and the last "problems" are in fact worksforme, as the import 
task is *intended* to pollute the project files that use it to be able 
to work as needed.

In most cases, one would want to use ,  or  
instead of importing buildfiles with s, which should be used 
only to reuse and "extend" a base buildfile.

--
Nicola Ken Barozzi   [EMAIL PROTECTED]
- verba volant, scripta manent -
   (discussions get forgotten, just code remains)
-
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

[Steve Loughran]

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 imported build file conflicting with 
one in the importer (i.e. lack of private scope)

-when you override a target, you dont get access to its dependents. 
Workaround: many pseudo-targets that only model dependencies.

-once you have sub-projects importing ../../common.xml, they are no 
longer self contained, which makes it harder to work with outside the 
existing build tree.

I dont see any good solution for the latter.
-steve
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

[Phil Weighill Smith]

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 having the importer depend on "foo"
> IMHO.  So in the normal case everything would look the same as today
> and in border cases we'll get an additional empty target.

If I understand what you're saying correctly, you don't expect importer
build scripts to depend explicitly on the renamed imported targets. I'd
disagree: we commonly "augment" the standard targets like this:

standard.xml:


...


build.xml:




...


I'm not sure if this is what you're discussing or not. What I can say is
that the output of targets and tasks used in our build scripts is very
unclear.

We generally find it difficult tell actually which target caused a given
dependency target to be executed because there are too many "empty"
target names being output (we have various targets that operate "if" and
"unless" variants, but the target name is output even if the condition
fails). In addition, the same "standard" targets are executed multiple
times during our build in different contexts since we have the concept
of "subsystems" within our build:

main-dir/build.xml "ant" executes:

main-dir/subsystem-one/build.xml
main-dir/subsystem-two/build.xml
main-dir/subsystem-.../build.xml

from within targets that have dependencies between each other that
describe subsystem dependencies. Each subsystem build.xml imports the
standard targets and executes them in its context.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

[Stefan Bodewig]

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 so it will be correct 8-)

> So what I take away from the above is that when there is only one
> "foo", the real work lives in "foo" while "bar.foo" depends on "foo"
> (my idea turned around).

Yes.

> 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 having the importer depend on "foo"
IMHO.  So in the normal case everything would look the same as today
and in border cases we'll get an additional empty target.

Stefan

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

[Nicola Ken Barozzi]

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 the case now).
Can't we have this as an addition anyway?
Why?
--
Nicola Ken Barozzi   [EMAIL PROTECTED]
- verba volant, scripta manent -
   (discussions get forgotten, just code remains)
-
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

[Phil Weighill-Smith]

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)!
 
Phil :n)

-Original Message- 
From: Matt Benson [mailto:[EMAIL PROTECTED] 
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:
>
> (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 "foo" yet.  Create an
> empty placeholder
>  target "bar.foo" that depends on "foo".
>
>  If then later a target "foo" is found in the
> importing buildfile,
>  replace the placeholder "bar.foo" with the
> initial "foo" target.
>
> Wouldn't that work, stay backwards compatible and
> hide "bar." whenever
> possible?

You confused me with the "later."  Even though this
could theoretically happen via 3rd-party API calls, we
wouldn't be able to detect it, would we?  Our local
targets are known before we actually execute a
top-level (target "") import, right?  So what I take
away from the above is that when there is only one
"foo", the real work lives in "foo" while "bar.foo"
depends on "foo" (my idea turned around).  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]:

-Matt
>
> Stefan
>
>
-
> To unsubscribe, e-mail:
> [EMAIL PROTECTED]
> For additional commands, e-mail:
> [EMAIL PROTECTED]
>
>



   
Discover Yahoo!
Find restaurants, movies, travel and more fun for the weekend. Check it 
out!
http://discover.yahoo.com/weekend.html


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

[Matt Benson]

--- 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 "foo" yet.  Create an
> empty placeholder
>  target "bar.foo" that depends on "foo".
> 
>  If then later a target "foo" is found in the
> importing buildfile,
>  replace the placeholder "bar.foo" with the
> initial "foo" target.
> 
> Wouldn't that work, stay backwards compatible and
> hide "bar." whenever
> possible?

You confused me with the "later."  Even though this
could theoretically happen via 3rd-party API calls, we
wouldn't be able to detect it, would we?  Our local
targets are known before we actually execute a
top-level (target "") import, right?  So what I take
away from the above is that when there is only one
"foo", the real work lives in "foo" while "bar.foo"
depends on "foo" (my idea turned around).  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]:

-Matt
> 
> Stefan
> 
>
-
> To unsubscribe, e-mail:
> [EMAIL PROTECTED]
> For additional commands, e-mail:
> [EMAIL PROTECTED]
> 
> 




Discover Yahoo! 
Find restaurants, movies, travel and more fun for the weekend. Check it out! 
http://discover.yahoo.com/weekend.html 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

[Stefan Bodewig]

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 if it does not override any target),

This implies that you'd know all target names of all files you import.
With the ideas of importing files you shipped within jars floating
around, I start to wonder whether this will hold true in the future.

> 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 the case now).

Can't we have this as an addition anyway?

Stefan

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

[Stefan Bodewig]

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 for all
targets, independent on how we achieve that.

> The fix will have a small overhead - the target object needs to be
> cloned and given a a new name, whereas the current code just renames
> the target object.

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:

(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 "foo" yet.  Create an empty placeholder
 target "bar.foo" that depends on "foo".

 If then later a target "foo" is found in the importing buildfile,
 replace the placeholder "bar.foo" with the initial "foo" target.

Wouldn't that work, stay backwards compatible and hide "bar." whenever
possible?

Stefan

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

[Matt Benson]

--- 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 discuss it on the list.

That's fine by me.  I was just kidding around--I do
that a lot but humor, esp. stunted humor like mine,
doesn't always come through in e-mail... ;)

-Matt


__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

[Stefan Bodewig]

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 some committer has talen
care of it, I tend to ignore subsequent mails from the report,  This
means I could be missing a discussion thread.

Furthermore I live and breathe in my mail client all day, I hate it
when I have to leave it to respond to a mail.  Some bug tracking
systems can be used by email as well, I even think Bugzilla could, but
not our installation.  If I have to start a brwoser in order to write
the two-character sequence "+1", I may just not do it.

Stefan

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

[Matt Benson]

(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 is currently done, otherwise there would
> be
> BC issues.

I can't imagine a scenario where BC would be
compromised, but I'd be glad for an example.

-Matt

> 
> Peter
> 



__ 
Do you Yahoo!? 
Yahoo! Mail - Find what you need with new enhanced search. 
http://info.mail.yahoo.com/mail_250

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

[Peter Reilly]

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:
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_bug.cgi?id=28444


--- Additional Comments From [EMAIL PROTECTED]  2005-05-12 17:34 ---
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 target
?
-Matt
 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

[Dominique Devienne]

> 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
> rename feature in this case?

I never liked target renaming either. Sure, renaming all targets is
more consistent, and I'm +1 for it, but it's still very flawed. 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 if it does not override any target), and have a "super"
target to possibly rely on, instead of "renamed" target. 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 the
case now). The "as" name used would then be supplied to the "super"
keyword.

Sorry, I couldn't resist bring all that up again. I know it's water on
the bridge, and that I lost this argument a long time ago, but it
still bugs me.

But eh, I gave my +1 to systematic target renaming ;-) --DD

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

[bugzilla]

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_bug.cgi?id=28444





--- Additional Comments From [EMAIL PROTECTED]  2005-05-12 17:47 ---
+1

That is similar to what I do in my preprocessor.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

[Matt Benson]

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 target

?
-Matt


The only issue with this is logging.  I guess it
really doesn't matter; the cloning approach shouldn't
be much heavier since it's as shallow as it is...

:)

--- Peter Reilly <[EMAIL PROTECTED]> wrote:

> 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?id=28444
> The example given is:
> 
> 
>
> 
> 
> 
>
>
> 
> 
> 
>
>
> 
> 
> Succeeds:
>ant -f A.xml x
>ant -f B.xml x
> 
> Fails:
>ant -f C.xml x
> 
> BUILD FAILED
> 
> 
> Target `A.x' does not exist in this project. It is
> used from target `B.x'.
> 
> 
> My comment is:
> 
> 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
> rename feature in this case?
> 
> The fix will have a small overhead - the target
> object needs to be
> cloned and given a a new name, whereas the current
> code just renames the
> target object.
> 
> The changes to ant for this is:
> Index: src/main/org/apache/tools/ant/Target.java
>
===
> RCS file:
>
/home/cvs/ant/src/main/org/apache/tools/ant/Target.java,v
> retrieving revision 1.58
> diff -u -3 -p -r1.58 Target.java
> --- src/main/org/apache/tools/ant/Target.java   10
> Mar 2005 12:50:57 -  1.58
> +++ src/main/org/apache/tools/ant/Target.java   12
> May 2005 14:41:25 -
> @@ -52,12 +52,28 @@ public class Target implements
> TaskConta
>  /** Description of this target, if any. */
>  private String description = null;
> 
> -/** Sole constructor. */
> +/** Default constructor. */
>  public Target() {
>  //empty
>  }
> 
>  /**
> + * Cloning constructor.
> + * @param other the Target to clone.
> + */
> +public Target(Target other) {
> +this.name = other.name;
> +this.ifCondition = other.ifCondition;
> +this.unlessCondition =
> other.unlessCondition;
> +this.dependencies = other.dependencies;
> +this.location = other.location;
> +this.project = other.project;
> +this.description = other.description;
> +// The children are added to after this
> cloning
> +this.children = other.children;
> +}
> +
> +/**
>   * Sets the project this target belongs to.
>   *
>   * @param project The project this target
> belongs to.
> Index:
>
src/main/org/apache/tools/ant/helper/ProjectHelper2.java
>
===
> RCS file:
>
/home/cvs/ant/src/main/org/apache/tools/ant/helper/ProjectHelper2.java,v
> retrieving revision 1.54
> diff -u -3 -p -r1.54 ProjectHelper2.java
> ---
>
src/main/org/apache/tools/ant/helper/ProjectHelper2.java
>26 Apr 2005 11:55:18 -1.54
> +++
>
src/main/org/apache/tools/ant/helper/ProjectHelper2.java
>12 May 2005 14:41:26 -
> @@ -815,38 +815,39 @@ public class ProjectHelper2
> extends Proj
>  + "a name attribute",
> context.getLocator());
>  }
> 
> -Hashtable currentTargets =
> project.getTargets();
> +// Check if this target is in the
> current build file
> +if
> (context.getCurrentTargets().get(name) != null) {
> +throw new BuildException(
> +"Duplicate target '" + name +
> "'", target.getLocation());
> +}
> 
> -// If the name has already been defined
> ( import for example )
> -if (currentTargets.containsKey(name)) {
> -if
> (context.getCurrentTargets().get(name) != null) {
> -throw new BuildException(
> -"Duplicate target '" + name
> + "'", target.getLocation());
> -}
> -// Alter the name.
> -if (context.getCurrentProjectName()
> != null) {
> -String newName =
> context.getCurrentProjectName()
> -+ "." + name;
> -project.log("Already defined in
> main or a previous import, "
> -+ "define " + name + " as "
> + newName,
> -   
> Project.MSG_VERBOSE);
> -name = newName;
> - 

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

[bugzilla]

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_bug.cgi?id=28444





--- Additional Comments From [EMAIL PROTECTED]  2005-05-12 17:34 ---
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 target

?
-Matt

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

[Peter Reilly]

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?id=28444
The example given is:

  


  
  


  
  

Succeeds:
  ant -f A.xml x
  ant -f B.xml x
Fails:
  ant -f C.xml x
BUILD FAILED
Target `A.x' does not exist in this project. It is used from target `B.x'.
My comment is:
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
rename feature in this case?
The fix will have a small overhead - the target object needs to be
cloned and given a a new name, whereas the current code just renames the
target object.
The changes to ant for this is:
Index: src/main/org/apache/tools/ant/Target.java
===
RCS file: /home/cvs/ant/src/main/org/apache/tools/ant/Target.java,v
retrieving revision 1.58
diff -u -3 -p -r1.58 Target.java
--- src/main/org/apache/tools/ant/Target.java   10 Mar 2005 12:50:57 -  
1.58
+++ src/main/org/apache/tools/ant/Target.java   12 May 2005 14:41:25 -
@@ -52,12 +52,28 @@ public class Target implements TaskConta
/** Description of this target, if any. */
private String description = null;
-/** Sole constructor. */
+/** Default constructor. */
public Target() {
//empty
}
/**
+ * Cloning constructor.
+ * @param other the Target to clone.
+ */
+public Target(Target other) {
+this.name = other.name;
+this.ifCondition = other.ifCondition;
+this.unlessCondition = other.unlessCondition;
+this.dependencies = other.dependencies;
+this.location = other.location;
+this.project = other.project;
+this.description = other.description;
+// The children are added to after this cloning
+this.children = other.children;
+}
+
+/**
 * Sets the project this target belongs to.
 *
 * @param project The project this target belongs to.
Index: src/main/org/apache/tools/ant/helper/ProjectHelper2.java
===
RCS file: 
/home/cvs/ant/src/main/org/apache/tools/ant/helper/ProjectHelper2.java,v
retrieving revision 1.54
diff -u -3 -p -r1.54 ProjectHelper2.java
--- src/main/org/apache/tools/ant/helper/ProjectHelper2.java26 Apr 2005 
11:55:18 -1.54
+++ src/main/org/apache/tools/ant/helper/ProjectHelper2.java12 May 2005 
14:41:26 -
@@ -815,38 +815,39 @@ public class ProjectHelper2 extends Proj
+ "a name attribute", context.getLocator());
}
-Hashtable currentTargets = project.getTargets();
+// Check if this target is in the current build file
+if (context.getCurrentTargets().get(name) != null) {
+throw new BuildException(
+"Duplicate target '" + name + "'", target.getLocation());
+}
-// If the name has already been defined ( import for example )
-if (currentTargets.containsKey(name)) {
-if (context.getCurrentTargets().get(name) != null) {
-throw new BuildException(
-"Duplicate target '" + name + "'", 
target.getLocation());
-}
-// Alter the name.
-if (context.getCurrentProjectName() != null) {
-String newName = context.getCurrentProjectName()
-+ "." + name;
-project.log("Already defined in main or a previous import, 
"
-+ "define " + name + " as " + newName,
-Project.MSG_VERBOSE);
-name = newName;
-} else {
-project.log("Already defined in main or a previous import, 
"
-+ "ignore " + name, Project.MSG_VERBOSE);
-name = null;
-}
+if (depends.length() > 0) {
+target.setDepends(depends);
}
-if (name != null) {
+Hashtable projectTargets = project.getTargets();
+boolean   usedTarget = false;
+// If the name has not already been defined define it
+if (projectTargets.containsKey(name)) {
+project.log("Already defined in main or a previous import, "
++ "ignore " + name, Project.MSG_VERBOSE);
+} else {
target.setName(name);
context.getCurrentTargets().put(name, target);
project.addOrReplaceTarget(name, ta

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

[Stefan Bodewig]

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.

Stefan

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

[bugzilla]

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_bug.cgi?id=28444





--- Additional Comments From [EMAIL PROTECTED]  2005-05-12 16:24 ---
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
rename feature in this case?

The fix will have a small overhead - the target object needs to be
cloned and given a a new name, whereas the current code just renames the
target object.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

[bugzilla]

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_bug.cgi?id=28444





--- Additional Comments From [EMAIL PROTECTED]  2005-02-01 17:34 ---
Adding an "optional if no conflict" prefix is insufficient. My scenario is a tad
different: I've got a 'framework' buildfile that imports local rules. I require
the local rules to define certain targets, so I know that e.g.
"local_rules.clean" exists (if it doesn't exist, an abort is desirable
behavior). There is also a automatically generated portion in a separate file. I
know what the filename/projectname is, so that's fine. 

But when developing a new target-set, not all of the local rules files or
framework files may be totally up-to-date. This only becomes irksome when one
component, that *KNOWS* someproject.sometarget exists, explodes because
"someproject.sometarget" is not defined--although "sometarget" is.

I don't know how the internals of import work, but I cannot imagine that adding
two namespace entries is a performance consideration of any kind. Please make
this behavior consistent.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

[bugzilla]

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_bug.cgi?id=28444

Import: Target Handling Bug





--- Additional Comments From [EMAIL PROTECTED]  2004-04-20 13:24 ---
Dominique, I think I was bouching for a different approach (XSLT like) at the 
time which also lost. In any case, under the current approach I tend to agree 
with you.

What I would suggest we can do now is the following:

1) Add a new optional attribute (e.g., "as") which declares a local (private) 
name for the import. The value of this attribute is the only name available to
refer to the imported targets.

 

2) The default value for the "as" attribute is the name of the  in 
the imported file. (That provides backward compatibility with the current 
behaviour).

Not sure if this simple rules are enough. I would really would like to keep it 
as simple as possible. And most of all avoid aliasing (i.e., the same target 
being accessible by two or more different full names.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

[bugzilla]

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_bug.cgi?id=28444

Import: Target Handling Bug





--- Additional Comments From [EMAIL PROTECTED]  2004-04-19 15:03 ---
Dominique, when you can, could you find the relevant thread?  I'd like to see 
what the con arguments were; seems to me it's still not too late to add one or 
more attributes to  to modify the current behavior...

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

[bugzilla]

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_bug.cgi?id=28444

Import: Target Handling Bug





--- Additional Comments From [EMAIL PROTECTED]  2004-04-19 14:48 ---
I'm not sure given the last post my point came across. I'm not against using 
using a prefix to resolve conflicts between imported targets and/or with the 
local importER's targets. I'm against using the importEE's project name as the 
prefix.

I can't import two build files (without modifying them) with the 'common' 
project name for examples. And it opens the door to weird edge cases in import. 
What I propose is that the import prefix be made optional (no need for it if 
there are no conflicts), and when necessary to disambiguate conflicts, the 
importER decide what prefixes to use in its OWN build script, and that 
additionally the prefixes used are completely private to the importER, i.e. an 
implementation detail to the importER.

Anyways, this battle was already lost, and the current behavior is here to 
stay. Not that it's that bad really, just poor design in my book. But hey, I'm 
surely wrong since I've been overriden by everyone. --DD

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

[bugzilla]

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_bug.cgi?id=28444

Import: Target Handling Bug





--- Additional Comments From [EMAIL PROTECTED]  2004-04-19 14:40 ---
I really don't think that allowing developers to qualify targets with their 
declaring project names is "bad practice."  Most languages that support a 
notion of override give you this fine degree of control.  Obviously, using a 
fully qualified target (.) when the unqualified one is 
sufficient isn't recommended (polymorphism is good).  But not leaving a 
developer with a consistent mechanism to ensure that the base/overridable 
target is always called in certain cases is a problem.

I'm not certain that we have to always make all targets referencable with the 
project name.  I'm sure this has performance implications.  So as DD suggests 
an import attribute that allows the importER to control the behavior sounds 
reasonable.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

[bugzilla]

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_bug.cgi?id=28444

Import: Target Handling Bug





--- Additional Comments From [EMAIL PROTECTED]  2004-04-19 14:16 ---
ALAS, what you guys are describing results from the use of the project names to 
prefix the targets. I was SQUARELY against such a bad practice, which breaks 
encapsulation.

With the model I proposed, no renaming took place, unless explicitly specified 
by the importER build, and the prefix used is local/private to the importER 
build. And I mean really private, i.e. somebody else importing that importER 
build never sees the prefixes used.

This removes all ambiguities one build file at a time, without affecting 
anybody potentially using/importing that build down the line.

At least I think this would have been a better scheme ;-) You guys are welcome 
to find edge cases that shows it wouldn't have ;-))). --DD

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

[bugzilla]

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_bug.cgi?id=28444

Import: Target Handling Bug





--- Additional Comments From [EMAIL PROTECTED]  2004-04-18 19:51 ---
I am aware that there are work arounds for the simple scenario that I provided,
such as managing the order of the imports and redefining the target in the file
where the problem arises.  Redefining targets merely to ensure consistent names
is undesirable and in a complex hierarchy of imports, managing the order might
not be a solution at all.

In any case, the inconsistency would not need to be managed if Ant always
qualified the target name with the name of the project, whenever it "could" be
needed.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

[bugzilla]

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_bug.cgi?id=28444

Import: Target Handling Bug





--- Additional Comments From [EMAIL PROTECTED]  2004-04-17 19:32 ---
Mike:  I have been playing around with similar concepts for days... however, in 
this case, knowing that B imports A, C would merely import B.  Or, had you 
imported B before A, thus defining x first, all would have been well.  OR, had 
C defined x, that would have been okay too.  I also thought it might be nice if 
there were a way to specify that imported targets would always be added with 
their "super" name, but I am undecided whether it's an entirely good idea... 
guess we'll see if Peter or anyone else has an opinion on this one...

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]