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 [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]
