Shouldn't there also be an option to download (maby embedded in the main build.xml for ant to download all tasks that depend on external sources? (like what they do in netbeans modules)They also use the build.xml to do this.
- You have a default stable distribution - You want e.g. the Junit tasks - You run build Junit - This target gets all the stuff that the junit task needs - Rebuilds ant when necessary. or - You're using the Junit task in a build.xml - If not present, throw a buildexception saying to get the junit optional and how to accomplish that. (maby offer it right away for download). - rebuild ant when necessary. Mvgr, Martin van den Bemt -----Original Message----- From: Bill Burton [mailto:[EMAIL PROTECTED] Sent: Sunday, January 21, 2001 4:02 AM To: Ant Developers Mailing List Subject: [PROPOSAL] Class dependency checking for optional tasks Hello, I've been thinking about ways to improve usability of Ant, particulary for first time users. Here's one idea in that direction. One of the questions that comes up a lot on the ant-user list is, "Where do a find the classes for ftp support, etc?" As a result, it was good to see Nico's patches to clarify the docs in this area. I've been thinking about this problem from a little different perspective. Overview Each task requiring external classes should provide a way the task developer can declare the required jar file(s) by specifing a class within each jar to check for the availability of the jar. If the class isn't available, the task will throw a BuildException with the name of the missing jar and the URL where it can be obtained. This feature is conceptually similar to the <available classname=... /> task but would force the build to stop if the specified class is not available by throwing a BuildException. Implementation Details Task.java would be modified by adding a method similar to the following (untested): /** * Tries to load the specified class ensuring any associated jar * file is available. If the class is not available, a BuildException * is thrown with the specified comment. The comment should concisely * provide information indicating what's missing and where it can be * obtained. * * @param name name of class to check in the classpath * @param loader class loader or null for the default * class loader * @param comment text describing the name of the class or * associated jar file and the URL or location where it * can be obtained */ public void checkForRequiredClass(String name, ClassLoader loader, String comment) throws BuildExeception { try { if (loader == null) loader = this.getClass().getClassLoader(); Class.forName(name, true, loader); } catch (ClassNotFoundException cnfe) { // Maybe this should also output the location too? throw (new BuildException("Missing class " + name + ": " + comment)); } // Need to catch other exceptions here? } The task developer could use it in either the init() or execute() methods like this: checkForRequiredClass("com.oroinc.net.ftp.FTPClient", null "Requires ORO NetComponents available at http://www.savarese.org/oro/software/NetComponents.html";); The <script> task could have many calls to this method, one for BSF and one for each of the supported scripting languages. If the consensus is that this is a good idea, I'll work on a patch for this functionality. -Bill Burton --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
