I think that agreement is very close.
What about this proposal:
The current types and tasks properties files may be combined
into a antdef.xml file of the form:
<antdef>
<taskdef name="acme" classname="org.acme.Acme"
onerror="fail/report/ignore"/>
...
...
</antdef>
Definer (in the form of <typedef/> or <taskdef/>) can use
this either as a file or as a resource.
<typedef antdef=".../ant-contrib.xml" classpath="${ant-contrib.jar}"/>
or
<typedef antdefresource="net/sf/antcontrib/antdef.xml" classpath="..."/>
or
<typedef antdefresource="net/sf/antcontrib/antdef.xml" />
(if antcontib-xyz.jar is in ${ant.home}/lib").
For convienance the antdef.xml may be placed a known place in the
meta directory of jar by the <antjar/> task.
The <antlib/> task (extending Definer), knows about this
known location and can then do.
<antlib file="${ant-contrib.jar}"/> or <antlib library="${ant-contrib.jar}"/>
where library is a convienance for ${ant.home}/lib.
An example-
<target name="init">
<mkdir dir="classes"/>
<copy todir="classes" >
<fileset dir="src" excludes="**/*.java"/>
</copy>
<javac srcdir="src" destdir="classes"/>
<antjar antdef="src/antdef.xml" destfile="acme.jar">
<fileset dir="classes"/>
</antjar>
</target>
<target name="all" depends="init">
<typedef antdef="src/antdef.xml" classpath="classes" prefix="typedef."/>
<typedef antdefresource="antdef.xml" classpath="classes"
prefix="resource."/>
<antlib file="acme.jar" prefix="antlib."/>
<antlib prefix="path.">
<path>
<fileset dir="." includes="**/*.jar"/>
</path>
</antlib>
<typedef.acme name="typedef.acme"/>
<resource.acme name="resource.acme"/>
<antlib.acme name="antlib.acme"/>
<path.acme name="path.acme"/>
</target>
I have code (which uses a lot of the ideas from the antlib proposal)
that implements the above. I will try to get it in a form ready
for upload to-nite.
Peter
On Wednesday 30 April 2003 15:16, Costin Manolache wrote:
> Jose Alberto Fernandez wrote:
> >> From: Costin Manolache [mailto:[EMAIL PROTECTED]
> >>
> >>
> >> My concerns with getResources() as oposed to
> >> getResource( PACKAGE/antlib.xml):
> >>
> >> 1. startup time. In order to load one library you need to process all
> >> of them. It can be resolved with caching the result and
> >> looking at .jar
> >> modifications. Most likley we'll have dozens of antlibs - and
> >> that'll only
> >> grow in time. The processing of (all) TLDs at startup ( for
> >> tomcat ) adds a
> >> very visible overhead on startup, and at least tomcat is a
> >> long-running
> >> process.
> >
> > I agree. But let me just say that I do not believe that in general
> > people should just shove evry jar in the world in ANT/lib
> > (this should be basically the core libraries).
> >
> > 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.
>
> 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 ).
>
> 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 ).
>
> >> 2. Placing multiple antlibs in a single jar may be trickier.
> >
> > I prefer to keep things simple, one antlib == one jar. It is the same for
> > all other things around ejbjars, wars, etc.
>
> "Prefer" is one thing, "require everyone" is another.
>
> 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.
>
> >> 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.
>
> > 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 ).
>
>
> Costin
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
