ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brett Porter <brett.por...@gmail.com>
Subject Maven and Ant collaboration on task codebase
Date Wed, 21 Sep 2005 04:19:03 GMT
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: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org


Mime
View raw message