ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Benson <gudnabr...@yahoo.com>
Subject RE: Antlib autoloading
Date Tue, 13 Sep 2005 15:04:04 GMT
--- Jose Alberto Fernandez <jalberto@cellectivity.com>
wrote:

> > From: Stefan Bodewig [mailto:bodewig@apache.org]
> > 
> > On Mon, 12 Sep 2005, Jose Alberto Fernandez
> > <jalberto@cellectivity.com> 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."

If we can satisfy both cases, so much the better, but
if not surely we must all see that we should err on
the side of caution (assume the user does NOT know
everything)?

-Matt

Please note that no slight to current or future Ant
users is intended here.

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



		
__________________________________ 
Yahoo! Mail - PC Magazine Editors' Choice 2005 
http://mail.yahoo.com

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


Mime
View raw message