> From: Costin Manolache [mailto:[EMAIL PROTECTED]
>
> Jose Alberto Fernandez wrote:
>
> > What I thought was to have a separate directory ANT/antlib
> (or something)
> > where people can put libraries which they can load easily on demand.
> > Something like:
> >
> > <antlib library="jboss-ant.jar"/>
> >
> > which will just look for ANT/antlib/jboss-ant.jar ant load
> that using the
> > classloader methanism whatever it is.
>
> That means more filesystem specific code. You can't use
> getResource() to
> get META-INF/antlib.xml from a specific jar - unless you're
> sure that's
> the only jar with that res. in the classloader. So you either
> operate on the
> jar with Zip, or you have to do ugly tricks with the loaders.
>
This to me is irrelevant, the <antlib> code needs to do what it needs
to do. getResources() is using zip or jar code internally anyway.
I have no problem on opening the file myself and looking.
There is no mistery on that.
> Plus - a lot of people have the strange habbit of placing the
> version number
> in the jar file name ( jboss-ant-1.2.3.jar ). Every time you
> upgrade an
> antlib, all build files that use the jar will need to change
> ( or you'll be
> forced to use indirection ).
>
So you allow wild characters. "jboss-ant-*.jar" we already have code
that is able to do search. The only thing it means is that the library
attribute is some sort of shortcut description for a <fileset>.
As I said, this to me are just details. What we need to fix is what
functionality we want for users.
> If you use namespaces - which seems to be what many people
> want - you'll
> either have to use ${} in the namespace ( I think most agree this is
> indeed a bad use of ns ), or the namespace will change if the
> versioned jars
> are used ( bad again ).
>
I am against using ns this way also, ns should be for elements disambiguity
and it probably should be more independent of where the actual jar is.
> If we place the descriptor in packages - both preferences are
> possible.
>
> Look - I'm fine with either solution, I just have a feeling
> that we're
> making the decision without really considering all
> implications. I don't
> like "versioned jars", and I don't like big jars combining
> too many things.
>
What does it mean to place the descriptior in packages? What is
the package for the ANT core? Is it org.apache.tools.ant or
org.apache.tools.ant.taskdefs or shall I also have org.apache.tools.ant.typedefs
And how about the tasks that live in other packages? I really do not
understand what is that this will give use. My point was that
you write one jar and you specify in the descriptor all the tasks on that jar
and that's it.
>
> >> 3. It may place too much emphasis on the .jars and
> filesystem layout.
> >>
> >
> > I still think that when you are really working on a
> project, you will have
> > your own directories in the basedir containing the antlibs
> required for
> > the project. And your buildfile will just load the antlibs manually.
> >
> > <antlib location="${myantlibs}/special.jar"/>
>
> Again - this will have implications in the namespaces.
>
There is no name spaces here. The fragment above just said load
the definitions on the jar. In case of collisions you get errors.
BTW <antlib> provides a mechanism to substitute names of components
to avoid collisions. Whatever names you define, is what should be
used on the buildfile.
>
> > or we could have something like:
> >
> > <antlib>
> > <fileset dir="${myantlibs}" includes="*.jar"/>
> > <antlib>
> >
> > or something of the sort. Having such a construct working fine for
> > manual loading would make providing an autoload just trivial.
> > The main() will just create the fileset for "ANT/lib/*.jar" and just
> > let the <antlib> do its job.
> >
> > My point is to provide the correct level of manual control and then
> > we can make a decision whether the bootstrapping process of
> ANT can just
> > run the task to do any autoloading.
>
>
> A lot of people ( myself included ) seem to like a "repository" that
> is shared by multiple projects - instead of having all the jars in CVS
> or managed manually.
>
> We must keep in mind this use case - and the fact that the file
> names may change ( versioning ) and the repository may have more than
> we need ( startup time, etc ).
>
I see no problem, just point to the repository as the dir for the fileset.
And you can use includes if you do not want to load everything.
Jose Alberto
