ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <nicola...@apache.org>
Subject Re: override
Date Fri, 08 Aug 2003 15:16:38 GMT

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 <import> 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 <import> 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* <projectref>. 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 <projectref> ?

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 <rename-target> target, or some <pre>/<post> or <extend>.
>>
>>In fact, as I have explained, Conor proposed <override-target>, 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:
>>
>><include>
>>
>>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.

>><override-target>
>>
>>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.
>>
>><import>
>>
>>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.
>>
>><Still conused about this [] part> [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 <override-target> or <target> to define a target
>>with the original name.
> 
> +1

<snip usecases>


> 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


Mime
View raw message