gump-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brett Porter <>
Subject RE: Maven Continuum != Gump
Date Mon, 01 Dec 2003 22:27:14 GMT
> Time marches on, Maven improves (I assume, I've 
> not yet used it) and I don't see why folks would want to use 
> Ant (for the simple 'build'/'test' portion of continuous 
> integration) if Maven meets it's goals.

I'm not sure the Ant folk would share your view here :) It's actually quite
amusing (and refreshing) to see this sort of opinion - usually it is the
direct opposite (why would I use Maven when I can already do all of that in

> I am really torn & looking for input.

I think the current direction regarding Maven is the right one. 

As far as collaboration goes, I believe that's what we are doing now. I look
forward to being able to gump projects using Maven. 

There is no ivory tower in that regard: if everyone got together and sorted
out exactly what was needed first, nothing would ever get done. Ant and
Maven co-exist: they do some things the same, they do some of the same
things differently, and they do completely different things sometimes.  This
isn't a bad thing, because you can't be everything to everyone. The same
will apply to gump and continuum and any other CI tools out there. There'll
be shared functionality and there'll be differing functionality. That's
fine. The important thing is that nobody is rewriting an identical app for
the sake of it, or rewriting components for the sake of it when the
functionality is already out there.

The future of Maven, as Jason blogged about and which is what started the
thread, is to become more componentised. Various useful bits and pieces such
as a Java SCM framework, artifact handling and more will be made available
to everyone, and everyone is welcome to join the lists and collaborate on
them too. I don't believe these are things that are already sitting around
at Apache.

Cheer up, everything is going to be ok :)


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message