Jose Alberto Fernandez wrote:
>> 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.
This is not an issue of "mistery". It is about how dependent we want
this to be on the filesystem, plus all the "small" issues.
( file names, locking the file on windows, etc ).
The difference between getResource() ( abstracted via classloader ) and direct
access to the
zip file is not "irrelevant" for most people.
>> 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.
Everything is a detail :-)
>> 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.
Another detail :-)
If it can't be the .jar name - we'll need another redirection and
elements to associate the ns with the jar file.
>> 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
Reverse it: the namespace for ant core is the package where we
decide to place antlib.xml.
I hope we'll have one in "org.apache.tools.ant" ( containing the
non-optional tasks and types ), and one namespaces for each
optional.
> 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.
In one case you place this descriptor in META-INF/antlib.xml, in the
other you place it in org/apache/tools/ant/antlib.xml, but you have
the option of providing multiple collections ( antlibs ) in a single
jar, you can use getResource() for any antlib in the classpath,
you can use the package as a namespace without any further indirection.
>> >> 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.
There is no namespace here - but as you know there are plans to add
namespaces. If we use the pacakge to identify an antlib, then this
can be used to load the tasks automatically using the ns declaration.
<project xmsns:antcontrib="net.sf.antcontrib" >
...
<antcontrib:if ... />
As long as antcontrib-VERSION.jar is installed in ant/lib or
some repository ( assuming we'll implement this ) - there is no
need for additional syntax for the user.
A namespace like that is a middle ground between a URL ( http://...
or file://.. ) and a meaningless UID ( 1000-000-123243423 ). If
they decide to change the package name - they would break a lot
of backward compat and it's reasonable to assume it is a new antlib,
so we can say that the package name is as "permanent" as the
corresponding library.
>> > <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.
Not that simple. Startup time problem, need to maintain the include
manually ( either the dir name or the jar name needs to include the version ),
etc.
I think this kind of "detail" needs to be taken into consideration, even
if it doesn't matter for you personally.
Costin
