> From: Matt Benson [mailto:[EMAIL PROTECTED] > > --- Jose Alberto Fernandez <[EMAIL PROTECTED]> > wrote: > > > > From: Stefan Bodewig [mailto:[EMAIL PROTECTED] > > > > > > On Mon, 12 Sep 2005, Jose Alberto Fernandez > > > <[EMAIL PROTECTED]> wrote: > > > > > > > 1) How about collisions? Well, how about > > collisions between classes > > > > in the classpath? > > > > > > Putting antlibs into namespaces was supposed to > > resolve those > > > collisions, just like namesspaces in C++. > > > > > > > And no one is saying that should not continue to be > > the case, but if I > > want to load something in the default name space, it > > is up to me to take > > the risk. > > > > > > How about loading a task that collides with one > > already defined in > > > > defaults.properties? What do we do in this case? > > Shall we react the > > > > same way? > > > > > > Sure, this (complain loudly) is what we're doing > > with multiple > > > <typedef>s for the same name as well. it may just > > be annoying, so > > > annoaying that people will avoid autoloading. > > > > > > > I do not buy too much this argument. If am > > "extending my ANT-CORE" with > > some 3rd party tasks is because that library does > > not collide with > > regular ANT tasks. This is the case of all the > > optional antlibs that we > > provide. And it may be the case of some specialized > > ant-libraries > > specific to some corporation. It is their job and > > their risk to try to > > cohabitate with the ANT tasks. Otherwise, they > > should use and declare > > name-spaces in their project files. > > > [SNIP] > > > > > > 3) Have an antlib.xml in META-INF for > > autoloading. My only misgiving > > > > on doing it this way is the duplication of > > declarations. > > > > > > Matt's example of using different names for > > autoloads (that end up in > > > the default namespace) and namespaced tasks would > > show an example of > > > when you want to have separate files. This may be > > a bit artificial, > > > though. > > > > > This to me is the worst that we can do to ANT. How > > are people going to > > understand that is you use auto-loading the tasks of > > some library have > > some name, but if you do not, then they have some > > completely different > > names, oh and by the way you ALSO need to define a > > name space for them. > > Is there any other way to make things more confusing > > for people trying > > to use reusable code? I doubt it. > > :) Jose Alberto, it seems that you and I have each > contradicted ourselves during this discussion. On > issue (1) above, regarding collisions, your approach > is to assume the user knows exactly what he/she is > doing: e.g. the name of every task provided with every > third-party distribution used. My thinking was the > opposite: a user might add things to Ant's classpath > that conflict and would need to be informed when > collisions take place. THEN, > on issue (3) above, your thinking seems to be the > opposite: we cannot trust that the user understands > the difference between global and other namespaces, > etc., in Ant, while the multiple antlib.xml approach I > [shall we say "suggested but did not necessarily > advocate"] seems to come from the perspective that the > user can be given choices, from which we can infer > that he/she would "know what they are doing."
Matt, I guess I should go back to my original starting point. I do not advocate that users put all their third party libraries inside the core name-space. I advocate using this mechanism, principally, for our own optional tasks, but also allowing some ANT installations to decide if some few specific libraries should be treated the same way, because of backward compatibility or something. My main issue is that our optional libraries should not have any more rights to live in core than anyone else's. We just guarantee they will not introduce some collision with core. As per (3) my point is that it sounds unreasonable to provide some facility that allows the same tasks to be known by different names. It would mean that every task will have to be explain twice or people will use sometimes one name and others other, without any real advantage but to be confusing for everyone involved. Jose Alberto --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
