> -----Original Message-----
> From: Sam Ruby [mailto:[EMAIL PROTECTED]
[snip]
> > 2. Alter Project.java to discontinue the use of the
> defaults.properties
> > files, and instead do a
> ClassLoader.getResources("meta-inf/antlib.xml"),
> and
> > process each of those on startup.
>
> Note: getResources is JDK 1.2. Is is the Ant community ready
> to make that
> leap just yet?
>
> I am not familar enough with this method, and the
> documentation is vague
> enough. If there are multiple jar entries on your classpath, with the
> standard system class loader find all of them?
Yes, one of the calls will return all of them.
> > 3. Add a new task "antlib" which can be used to load a jar file
> containing
> > ant tasks and datatypes. This would be used in case
> someone doesn't want
> to
> > drop their antlib into $ANT_HOME/lib.
> >
> > e.g.
> > <antlib file="foo.jar"/>
>
> Count me in those that don't want to drop jars into $ANT_HOME/lib.
then don't. :-)
just kidding. I'm open to (and in favor of) forcing the non-core
tasks/libraries to be explicitly defined, I've just heard a number of people
request that capability.
> Shouldn't antlib accept a Path specification? I'd also like
> it to respect
> the value of build.sysclasspath.
My only concern with that is what are we saying constitutes an antlib? My
original vision was that the antlib call would take a single file, but
there's no reason to make that restriction.. If we opened it up to using a
path, we're pretty much back to what you can do today with:
<taskdef resource="meta-inf/ant.tdf">
<classpath>
<pathelement location="mylib/mytasks.jar"/>
</classpath>
</taskdef>
Which has been accused of being an "ugly hack". :-)
What I'm really trying to do with this is to make it very simply for
companies or third parties to package up a set of tasks for widespread use.
Given that anything <antlib> can do can also be done with <tasklib> I'd
recommend keeping <antlib> nice and simple.
>
> > 4. Separate the definition of the optional tasks and types into the
> > meta-fin/antlib.xml file in the optional.jar.
>
> typo: meta-inf.
thanks.
>
> > Please reply with your +1, 0, or -1 vote to the group.
>
> Can I wait for answers to the above first? ;-)
>
> I don't know if it can be addressed at the same time, but as
> more projects
> define tasks for their own use, one thing to consider is
> adding the ability
> to define tasks which are built during the build process. Perhaps an
> antlib task could allow nested javac and jar elements. The
> javac tasks
> would simply be executed in order. The jar tasks would not
> only execute
> but the results would be added to the path.
I'd rather not add the nesting... you simply do the javac & jar previous to
calling <antlib>.
Tim
