From: "Peter Donald" <[EMAIL PROTECTED]>
> > Once you accept this there is no reason to enforce that libraries are
> > located in some especific place, they can be anywhere including a remote
> > location. ANT may provide a convinient location (${ant.lib}) but it should
> > be just that a convinience.
>
> Sounds like a type.lib.path to me ;)
>
See my comments below.
> > The next question is how this libraries interact with ClassLoaders. Should
> > each library have its own ClassLoader?
>
> +1
>
> > Should they be able to share them?
>
> -1 the contract of tasks is at XML/TaskModel level and we shouldn't need
> interaction *unless* you inherit from one. (ie extend zip to create war or
> similar). These however can just be considered an "external library". This
> means in a few rare cases we will load certain task classes in multiple
> ClassLoaders but as they can't interact with each other this should not be a
> problem.
>
This sounds fair. Notice that am just teasing by putting every posibility on
the table and let all of us vent our opinions about it.
> > How about external libraries being required?
>
> I think we should go with the standard java mechanisms for "Optional
> Packages" (see jdk1.3 docs) combined with the ancient Class-Path: foo.jar
> approach. This is what all new APIs are moving towards and is fairly
> flexible. About the only irritating thing is that there is no standard to say
> 2.0 is incompatible with 1.0 version of same library ;(
>
I would like to explore this more.
To start with, if this mechanism is so good, why aren't we using it in ANT
already?
Why is our shell/batch script putting things in the CLASPATH?
Following this line, the correct thing to do would be to specify all the jar
dependencies for ANT core in ant.jar itself and let the JVM made up the
classpath. Hence we would be able to just do "java -jar $HOME/bin/ant.jar $@"
or equivalent.
In any case, in ANT, any additional jars should be declared in the classpath of
the tasks (which are not core) that need it.
> > Shall one be able to specify
> > an additional ClassPath for the library?
>
> besides above I would be -1
>
> > <tasklib name="lib1" location="mydir/mytasks.jar" />
>
> I am also -1 on specifying location. We should just give name of library and
> it can be searched for on type.lib.path or whatever.
>
The problem with this approach is the assumption that every ANT user has
administration rights over its ANT installation. Although that may be the case
in most cases, there are shops that have automounted /bin directories
reflecting the standard of the shop. In such cases not be able to declare
things outside the predefined locations is a problem. Which I presume is a
problem people have with JVM extensions also. What do you do on
shared/globally-administered environments.
Furthermore, what is a library's name? The only names we really have (without
some auto-intall/find facility) are filenames so between saying
'library="mytasks.jar"' (to be found in some path) and allowing people to use
libraries relative to the project being build, 'location="mydir/mytasks.jar"'
for example, seems like very little difference. I would not mind allowing both.
I have had projects where local tasks are build as part of the project, since
these tasks need to be made available to end-users, they should be build into a
library and used within the same project. Just like I can do with individual
taskdefs today.
Notice by the way that in my above syntax the attribute "name" was a way to
declare namespaces, to use to avoid clashing. We could definetly use something
else, if we really think this type of namespace support is really useful. am
not completely sure at this point.
Cheers,
Jose Alberto
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
