Trying to summarize. Costin Manolache wrote, On 08/08/2003 16.21: > Nicola Ken Barozzi wrote: ... >>As has been pointed out in these threads, Ant is a different beast, and >>should be treated differenty. > > +1 > >>>We are talking about OO concepts and inheritance - in context. >> >>Well, we are not. We are referencing those concepts, but it's not the >>same thing. > > Still - replacing/overriding targets in import is very confusing, even on > ant-dev. > > My point is that we should eliminate ambiguities - but not by adding more > flexibility and complexity into the import task. ACK >>>If we have so much trouble understanding how would be used >>>for inheritance, what about all the users who may be java programmers >>>( where import has a very intuitive meaning, and so does extends ). >> >>If it's just a naming issue, let's call it XYZ, I honestly don't care. >> >>Just to be clear: current import is *not* . It is not meant >>to encapsulate another buildfile, and the basedir resolving and the >>non-namespacing of properties is very clear about this. > > What is ? I have to reread the mails to get to that point? No way ;-P I'll just explain brieflt OTOMH, Conor can be more precise. In essence it's about having ant buildfiles instanciated in parallel, and have make it possible for them to share dependencies. So a target in project A can depend on a target in project B, and the two builds are completely isolated in their own basedir-properties-targetnames. IIRC there is some docs in Conor's Ant2 proposal. >>Ok, so you haven't read all the thread ;-) >>Maybe it's better if you take a bit of time to reread the thread, as we >>are repeating stuff here. > > I'm working on that :-) If I repeat some opinions - that's good. :-) >>>If you import 2 files, each having a "compile" target, then you should >>>use qualified names. Like in java import. >> >>Ok, this is clear, you are saying we should not have an automatic >>"winner" in case of multiple colliding import names. > > Yes. Having a "winner" is what creates confusion, ambiguity and the > need to rewrite or define import as an OO construct. >>>Just use a target, or some 
/ or .
>>
>>In fact, as I have explained, Conor proposed , and I
>>like it. But this is only about a a single import, the real issue
>>discussed here is the multiple one.
> 
> I like it as well, but I don't agree that it is about a single import, it
> can be very well used inside a single file, with no import at all.
> 
> If we agree on qnames ( and implicitely no "winner" or conflicts in import),
> then override-target and all that becomes even more powerfull - you'll have 
> access to _all_ targets, including the loosers.

That's the idea behind the current import stuff, so it fits perfectly.

>>>>Second question: how do we deal with the fact that targets that are not
>>>>even used have crosstalk between themselves?
>>>
>>>I don't think you can have crosstalk if you follow the rule that
>>>everything is qualified if it has the same name.
>>
>>Two points here:
>>
>>  - Crosstalk can happen in form of properties
>>  - Of course you won't have crosstalk if you use qualified names, this
>>    is what Conor says
> 
> Again, I agree with Conoer :-) That may mean he is right ?
> 
> I haven't tought about qualified names for properties, but it makes sense
> too.

Noted.

>>Let's see:
>>
>>
>>
>>No problem here, any collision is an error
> 
> I don't quite see a need for include ( given my view on import :-), but
> if other people need it - fine with me.

Well, some +1ed it, so since it's a subset of the import functionality, 
I'd say "why not" too.

Basically it should be simply a 1-1 replacement with entity includes.

>>
>>
>>I am overriding the previous defined target, and can refer only to the
>>immediately previous one as original.targetname. Overriding can be done
>>multiple times, nesting the calls.
>>
>>
>>
>>Like include, but gives me the possibility of referring to the imported
>>tasks with a fully qualified name in any case. If there is only one
>>version of a target, it's also available with the original name.
>>
>> [The "namespace" name has to be
>>specified as a prefix by the one that imports the file, else the project
>>name is used. Projects that are imported must have a name.]
>>
>>If a project imports clashing target names, and thus namespacing is
>>needed, I can still use  or  to define a target
>>with the original name.
> 
> +1




> I'm starting to like override-target :-)

:-)

BTW, we have renamed cents to antlibs, Centipede is just a task, and we 
are splitting functionality in various tasks, as you have suggested.
It's looking good :-)

>>Thanks for taking time to discuss this guys, I appreciate :-)
> 
> Sorry for repeating what has been discussed, I was very concerned about
> mixing import with OO and complex name resolution rules ( like in XSLT
> import :-)

You have maybe repeated some (small) parts of the discussion, but you 
have been very good at making your point, which in fact was exactly the 
last point of contention. :-)

What remains is Jose Alberto's POV, that probably can be summarized in 
this part he wrote:
"
The probelm with this is that it does not allow you to write code
fragments. Like several blocks of initializations that can be
reused but do not define a full build process.
"

I'd like to remind him that *if* there are no name contentions, the 
above would still remain perfectly possible.

What differs is that ATM in case of contention, import declares a 
winner, which is the last declaration, while the new import would need 
an explicit override-target.

So the point becomes if it's auspicable to have automatic or hand-made 
multi-target contention resolution.

MHO is that the automatic-resolution system has a relatively limited 
use, but a big possibility of abuse, so I stand behind the "manual" one.

Jose, anything to add? Usecases to show?

-- 
Nicola Ken Barozzi                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org