Hi, I'm basically looking for some opportunities for sibling Apache communities to work together in an area we have some overlap, and wanted to see what thoughts the Ant community had on this. I've invited folks on the Maven lists to follow this thread here too, so if you see some strange faces - that might be it.
This has been discussed before here briefly by myself and Vincent Massol, and is also inspired by the original Ant2 proposal by Peter Donald which he has reviewed recently: http://blogs.codehaus.org/people/vmassol/archives/001036_id_love_reusable_ant_tasks.html http://codemyth.blogspot.com/2005/09/no-shared-vision-no-ant2.html I'm not asking to revisit something that has already failed, BTW, but am looking for a best path forward. Maven is finding ourselves in the position now of wanting to reuse a lot of the Ant task code. Some that particularly spring to mind: - Exec - compiler tasks - archiving (jar, zip, tar) We're not the first to have encountered this: other projects have forked this code before. Eventually, the archiving tasks found their way to jakarta commons-compress, and I've recently started commons-exec with others to try and build reusable code from the Exec tasks. commons-jci exists which came from Cocoon and could potentially be merged with the Ant code for javac. There are others like commons-io that share much code with Ant. At this point, I'm hoping to start fleshing them out and using them instead of our own forked versions (that mostly came via Avalon and have since permuted). On the flip side, Maven has a number new tasks we are building that could be used in Ant. We've already done so for dependency management, but we have libraries for SCM (support for CVS, SVN, Clearcase, Perforce and Starteam and IIUC it goes beyond the support provided by Ant), Wagon (scp/sftp/http/ftp/file/scm transport through a common API) and we are also planning others, like a generic issue tracking interface library. Probably most notable would be the various reports like the SCM change logs, release notes, and so on. Then there are others we have started together (and not progressed much yet): commons-openpgp. I think there is a definite need for these libraries to be separate from Ant so that they can be used in other places where Ant is not available. I know you can use Ant via the Java API, but Vincent illustrates that it can be a bit verbose, and you end up with a rather large dependency full of unneeded tasks and bindings to the Ant project. These are still options under Maven though, BTW - there are several ways to use Ant "as is" if that is the best solution for the person in question. My main concern is that with all these libraries, that the refactoring may not be used in Ant, which means that should Ant expand or fix bugs in its code, that is not propagated to the code others are using. So, my question is - what is the road map for Ant 1.8 (possibly 1.7) and beyond? It seems antlibs is becoming the way to extend Ant - is it possible that more of the task code may be moved into that? If so, is it possible that task code may be decoupled from Ant, or a smaller set of types might be established? For example, Maven2 plugins can run without dependencies (like in ant, by reflecting execute), but also has a 5K library with an implementable interface and logging provision. I understand some tasks may require the basic fileset/path/etc support - could they be made into a smaller API to allow better separation of the antlibs? Does the practice of creating commons libs like we have been doing work for Ant, and would you accept patches to integrate them back into Ant? I think this is the best first step, but see a few issues: - backwards compatibility: Probably fine for the task usage, but I'm not sure of the public API of the tasks may already be in use in java code that could be affected by this - JDK requirement: we've typically moved to support a minimum of 1.3 and sometimes 1.4 - JAR hell: harder to bootstrap Ant given dependencies that probably need Ant to build (we encounter the same issue with Maven), and don't want to get into issues of someone using different versions of the libraries in their own tasks if it conflicts with Ant. Should be easily overcome by repackaging/recompiling the sources of the commons libraries with a new package for the main Ant distributable (which brings it back to the current solution at runtime, but allows more flexibility for those that use the code aside of Ant). Of course, if it is not seen as beneficial to Ant in any way, then I'm happy to continue building up the common libraries as we've started, and run the risk of having to fix similar bugs. The stability of the Ant code base suggests this risk is quite low. What benefits are there for Ant? A warm fuzzy feeling? :) As I mentioned, I hope that Maven will produce more plugins that are useful from Ant. We also have a growing and active community that code at Apache (and those that build plugins outside of Apache due to licensing issues). We even have a few Ant-only users that are getting more involved in Maven due to the availability of the Maven dependency tasks for Ant that could hopefully grow into contributors not only to those but other antlibs. Again, not looking to make a call to action, but just to make sure we're all facing in the right direction and can naturally move to a way to better collaborate. I look forward to your thoughts, opinions and flames :) Thanks, Brett --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
