Discussions

News: Using Antlibs with Ant 1.7

Bookmark and Share Get thread feed

  1. Using Antlibs with Ant 1.7 (8 messages)

    • Posted by: Regina Lynch
    • Posted on: August 10 2006 12:41 EDT
    With a new release of Java-based build tool Ant approaching, Kev Jackson provides a tutorial on using antlibs, a new feature that helps create and distribute custom Ant tasks, types, and macros, and distribute the optional tasks included with the Ant distribution. According to Jackson, antlibs are a solution to problems presented by taskdefs, including classpath lookups, distributing custom tasks and tight coupling of optional tasks.
    • By default, antlibs are placed in $ANT_HOME/lib and specified using XML namespaces.
    • The antlib format provides a good standard method of distribution (single .jar containing tasks, types, and macros, together with an XMLdescriptor).
    • Optional tasks can be de-coupled from the Ant core code and released on a different schedule.
    The antlib feature allows developers of Ant tasks to ship fixes and updates independently of the main Ant distribution.
    An antlib is simply a collection of classes bundled with an XML descriptor file. Typically, an antlib is distributed as a .jar file, but this isn't a strict requirement. The root element of the XML file is . Any classes can go into the makeup of an antlib, but only some classes can be declared in the antlib.xml file.
    Jackson also describes the AntUnit antlib, a quicker method of creating unit tests for Ant tasks.
    Another new facility provided by Ant is the AntUnit antlib. Unlike a JUnit TestCase or a BuildFileTest, AntUnit allows you to specify your tests without using any Java code.
    Jackson goes on to write the start of an antlib for the SCM system Arch to show how to develop new tasks with the antlib mechanism. He also tests this antlib with an AntUnit test. What do you think of these soon-to-be-available features?
    Reply to this

    Threaded Messages (8)

  2. Re: Using Antlibs with Ant 1.7[ Go to top ]

    How about the ability to load Ant build files from a jar so I can package up a set of reusable ant build files and import them from the classpath?
    Reply to this Reply to original

  3. Loading from jar file[ Go to top ]

    There is a package out there called AntWorks with can load from a .jar file and/or directory structure to provide re-usable targets. It hasn't been updated in about 2 years it seems, but it's basically just an extension of the task. It downloads the .jar file, looks for a resource named "xbuild.xml", extracts it to a temp directory, and then imports that file. Kind of an ugly workaround, as it really limits you to a single file (no properties files or anything) in the jar, but it will do what you want. http://antworks.sourceforge.net/
    Reply to this Reply to original

  4. Re: Using Antlibs with Ant 1.7[ Go to top ]

    Antlibs are not a specific feature of Ant 1.7: they are already present in version 1.6.5. ________ MessAdmin, J2EE administration made easy!
    Reply to this Reply to original

  5. optional jar dependancy[ Go to top ]

    i would really like to see ant resolve the optional jar dependancy issue. if you're using the junit task, you've got to put the junit.jar in the ANT_HOME/lib folder, or in ~/.ant_lib (something similar), or modify the system classpath. sometimes you just don't have the flexability to do these things and want to use these core tasks. you can't even use taskdef with a classpath since the base classes were already loaded by another parent classloader. my solutio^^^hack was to take the ant sources and move the supplied optional tasks to another package (foo.org.ant.apache.whaterver) and then i could use a taskdef with a task of m_junit or somesuch. i'd like to see ant provide the tasks as is, and also provide tasks such as e_junit or somesuch with the libs in an ANT_HOME/external/lib/ folder that i can use w/o having to modify the target environment.
    Reply to this Reply to original

  6. Re: optional jar dependancy[ Go to top ]

    i would really like to see ant resolve the optional jar dependancy issue. if you're using the junit task, you've got to put the junit.jar in the ANT_HOME/lib folder, or in ~/.ant_lib (something similar), or modify the system classpath. sometimes you just don't have the flexability to do these things and want to use these core tasks. ....
    I share your frustration at this ... Hopefully Ant 1.7's approach is a big improvement over 1.6, though Ive yet to try it. just fyi on junit, the workaround i use is not to fork a seperate java task to run the unit tests... Something like ... <!-- <java fork="true" failonerror="true" classname="org.junit.runner.JUnitCore" > <arg value="...t.b...s.TestClassName" /> <classpath refid="test.classpath" /> </java> --> At least then you can release something the builds with a standard JDK and standard ANT distribution... Incidentally, 1.6.5 is still listed as the official release on the apache site, it has been out for over a year now, I would have thought that there are enough patches to optional tasks (junit etc) to justify a 1.6.6 given the above limitations... Does anyone know if 1.7 is released or if theres a target date for 1.7?
    Reply to this Reply to original

  7. Re: Using Antlibs with Ant 1.7[ Go to top ]

    What do you think of these soon-to-be-available features?
    Hmm, these "soon-to-be-available features" are existing for about 2 years now and where introduced with Ant version 1.6. I don't understand why the antlibs provided on the apache ant site claim that they need ant version 1.7.x. AFAIK, 1.6.5 is the latest ant version - and I haven't seen any plans for releasing a 1.7.x version yet. Regards, Dirk
    Reply to this Reply to original

  8. Ant 1.7[ Go to top ]

    The claim to need 1.7, because they do. They are developed against the latest source code. At least the AntUnit library is.
    Reply to this Reply to original

  9. Re: Ant 1.7[ Go to top ]

    The claim to need 1.7, because they do. They are developed against the latest source code. At least the AntUnit library is.
    That's what I suspected, but refused to believe. Of course, this makes these antlibs absolutely worthless ... until a stable, production-ready version of ant 1.7 is available :-( Regards, Dirk
    Reply to this Reply to original