Return-Path: Delivered-To: apmail-jakarta-commons-dev-archive@apache.org Received: (qmail 61288 invoked from network); 23 Jun 2002 02:18:10 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 23 Jun 2002 02:18:10 -0000 Received: (qmail 19617 invoked by uid 97); 23 Jun 2002 02:18:15 -0000 Delivered-To: qmlist-jakarta-archive-commons-dev@jakarta.apache.org Received: (qmail 19574 invoked by uid 97); 23 Jun 2002 02:18:14 -0000 Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Jakarta Commons Developers List" Reply-To: "Jakarta Commons Developers List" Delivered-To: mailing list commons-dev@jakarta.apache.org Received: (qmail 19562 invoked by uid 98); 23 Jun 2002 02:18:13 -0000 X-Antivirus: nagoya (v4198 created Apr 24 2002) To: "Jakarta Commons Developers List" Subject: Re: unmavenising Commons projects MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_M13_04302002 Pre-release 2 April 30, 2002 From: dion@multitask.com.au Message-ID: Date: Sun, 23 Jun 2002 12:31:04 +1000 X-MIMETrack: Serialize by Router on gateway/Multitask Consulting/AU(Release 5.0.8 |June 18, 2001) at 06/23/2002 12:31:12 PM, Serialize complete at 06/23/2002 12:31:12 PM Content-Type: text/plain; charset="US-ASCII" X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Costin, Maven is about more than just build files. Notice how some commons sandbox components now have a web site. Even commons components like dbcp took a long time finding the motivation to get a web site together. Maven doesn't just do builds, it produces reports, confirms tests, can produce coverage reports for test cases, ensure coding styles are adhered to and reported on, show cvs history and activity and much more. Given one of my pet gripes with commons and sanbox was the complete lack of documentation, Maven at least is a step in the right direction. Again, how much of the existing maven process must be available in a vanilla ant build file? -- dIon Gillard, Multitask Consulting Work: http://www.multitask.com.au Developers: http://adslgateway.multitask.com.au/developers costinm@covalent.net 06/23/02 07:13 AM Please respond to "Jakarta Commons Developers List" To Jakarta Commons Developers List cc bcc Subject Re: unmavenising Commons projects On 21 Jun 2002, Jason van Zyl wrote: > If we are going to do that then we should also specify a standard which > is the point of Maven: to unify the build process. Commons components I don't think you can 'unify' the build process by forcing everyone to use a single style and stop using 'legacy' ant. Even with all the problems it has, gump shows very clearly that it is possible to create an unified build process where each project can keep it's own style. I don't think I'll use maven to build projects until it is at least at the same level with gump. If you can make Maven to use the existing build.xml files ( which shouldn't be very difficult, if Gump can do it with shell and xslt ) - I'll switch to maven. If you can support the gump project descriptors, then all jakarta will be buit with maven, and I don't think anyone could complain. As for 'common policy/style' for all commons packages - yes, it would be nice, but so far we don't seem to have any agreement on this. And that's a pretty good sign that it's the build system that should be able to adapt, instead of forcing everyone in jakarta to adapt to a new build system. This has nothing to do with the subject of this thread - which is the requirement to discuss and vote on major changes, like deprecating the ant build file ( which happened in commons ). Costin -- To unsubscribe, e-mail: For additional commands, e-mail: -- To unsubscribe, e-mail: For additional commands, e-mail: