ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Dawson <tdaw...@wamnet.com>
Subject RE: PROPOSAL: loading tasks from jars for Ant 1.5
Date Wed, 10 Oct 2001 19:13:30 GMT
> -----Original Message-----
> From: Sam Ruby [mailto:rubys@us.ibm.com]
[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

Mime
View raw message