Return-Path: Delivered-To: apmail-jakarta-commons-dev-archive@www.apache.org Received: (qmail 59646 invoked from network); 4 Dec 2005 02:17:30 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 4 Dec 2005 02:17:30 -0000 Received: (qmail 83562 invoked by uid 500); 4 Dec 2005 02:17:11 -0000 Delivered-To: apmail-jakarta-commons-dev-archive@jakarta.apache.org Received: (qmail 83085 invoked by uid 500); 4 Dec 2005 02:17:08 -0000 Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: 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 83034 invoked by uid 99); 4 Dec 2005 02:17:07 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 03 Dec 2005 18:17:07 -0800 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: domain of mfncooper@gmail.com designates 64.233.184.205 as permitted sender) Received: from [64.233.184.205] (HELO wproxy.gmail.com) (64.233.184.205) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 03 Dec 2005 18:14:03 -0800 Received: by wproxy.gmail.com with SMTP id i11so379651wra for ; Sat, 03 Dec 2005 18:13:42 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:references; b=GxtpBN6PklhOC2Z1I9jp0n7cRWewsRm5/JZE5dzRjqocLC0zz5hpSypDLvdrZpRnrZQoeb1Ml9YphtmVQ/eMkM61LokyywtbddExuDRBdRf0v6ucWfAOzLgbLklOUoNGDORaIMCPcNNxQwvFWzymYgRHieE9bFMv9+KjzITZYiI= Received: by 10.65.251.13 with SMTP id d13mr18464qbs; Sat, 03 Dec 2005 18:13:42 -0800 (PST) Received: by 10.65.97.6 with HTTP; Sat, 3 Dec 2005 18:13:42 -0800 (PST) Message-ID: <16d6c6200512031813v7e375dfbs38b1da84485d18c3@mail.gmail.com> Date: Sat, 3 Dec 2005 18:13:42 -0800 From: Martin Cooper Sender: mfncooper@gmail.com To: Jakarta Commons Developers List Subject: Re: [all] Maven, help or hinderance? In-Reply-To: <31cc37360512031753m41177393pd391e2484db0408@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_17789_23351644.1133662422217" References: <43828F71.1020107@javactivity.org> <43920459.2050906@eircom.net> <43920C7E.3030502@javactivity.org> <8a81b4af0512031329m2e26d11fpc5db2292642d6770@mail.gmail.com> <4392132A.4050506@javactivity.org> <8a81b4af0512031358u26334478j4f13e475a72349ad@mail.gmail.com> <43921DFC.4010406@javactivity.org> <31cc37360512031643u54955397i90974dab530fd239@mail.gmail.com> <439243AA.3030302@btopenworld.com> <31cc37360512031753m41177393pd391e2484db0408@mail.gmail.com> X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N ------=_Part_17789_23351644.1133662422217 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On 12/3/05, Henri Yandell wrote: > > On 12/3/05, Stephen Colebourne wrote: > > >>Hate to be an "old fart" here but was ant really all that bad? > > > > Well it is a question isn't it? I suppose this is a flame thread, but I > > have to ask, have we over the last two years or so actually got the > > benefits that maven promised? And do we believe that maven2 will help? > > It got simpler and easier, but then we started to push and it got > harder. Then we noticed that there were problems (such as building for > 1.2) and it got much harder. > > > When I think of maven, I see the POM as a good idea, raising the > > abstraction level. The problem has always been what it does with the > > POM. > > POMs are nice. Standardisation is nice, especially in the workplace, > but also in something like Commons. > > Maven's been a huge plus in my dayjob because my colleagues have not > needed to know Ant. They've also not needed to know Maven; we stay > within the lines and it becomes a shiny red button. Helps that we > don't have to release sites for each release too. > > Commons components like to colour outside the lines though, and our > Maven usage is less cozy I think (and I say that as a Maven fan who > often doesn't even have Ant installed on a development machine). I'm really not sure what that paragraph means. ;-} "colour outside the lines"? "less cozy"? Now that I'm used to it, I'm quite happy with Maven fo= r the components I work on (and Struts). > I have a feeling that maven should have just been a set of ant > > tasks that used the POM for info. Anyway, that design wasn't chosen. > > Was at first, but Ant proved to be too painful to use for the things > they were trying to do, thus Jelly. Which bizarrely I've actually come > to quite like :) > > > So what works well with maven? > > Standardisation of commands, pom, dependencies. I think the remote > dependencies works really well, and I'm quite happy that I don't have > to mess with build.properties files and putting jars in the right > place on the dev box. Huge +1 on that. However, there are lots of things in Ant that do that now. > > > Well the end result site can be quite > > reasonable. You still have to put in effort though, to fix > > navigation.xml, cvs-usage.xml, issue-tracking.xml, add decent links to > > each of the reports, manage the history of javadocs... > > I turn the navigation off on Maven projects. Can't stand the > project-reports, project-info roll-ups that make it harder to find > javadocs etc. It's quite easy to leave them where they are (so that people who are used t= o Maven sites know exactly where to find them) as well as add links to (some of) them from elsewhere. The latest updates to the IO, Validator and FileUpload sites do that, and I think the combination works well. > Building has always seemed to be a nightmare though. I have no faith > > that the jar or dist built by maven is the jar/dist that I want (I > > always want something non-standard). And one output jar per project is > > just crazy (see collections-testframework for example). And we still > > don't have a cast-iron way to build a 1.2 compatible release using > maven. > > I've not had problems, but I stay within the lines. At work we only > use 1.4.x, so less worry about JDK versions and for osjava.org I let > the JDK pain hit the small number of (elite) users :) > > Our need to release for Java 1.2 is a definite roadblock for Maven > usage. I like the one output jar per project, it keeps them as honest > components :) ie) no commons-collections-primitives without us > deciding we want it. It also keeps it very standard; no worries about > what the output of the component is, it's always > groupId-artifactId-version.jar. So nice to do macro-Commons things > like nightly builds. > > > So, are we holding on to maven because we feel we should? Are the > > claimed benfits really there? And if I'm already using ant for releases= , > > why shouldn't we do as Hen suggests and generate our reports outside > > maven too? > > And do we need that many reports :) Personally I think reports are the > job of the nightly build system; the site is about links to released > artifacts. If the site-dev@ thing ever gets off the ground, the sites could be refreshed on a daily basis, at which point, having the reports as part of the site would be really nice. Online javadocs for version 0.7 of a component are essential. Maybe > the source xreference, but after that it gets less interesting. > > Not that I'm suggesting generating the reports outside of Maven as > Stephen thought. I'm suggesting that we handcraft > (Forrest/xdoc/xml/something) our website and use Maven to generate > artifacts to be distributed and linked to, not the site itself. No thanks. I'm happy using Maven for that, and very much dislike the prospect of having to install, learn and use some other custom-built doodad= . -- Martin Cooper Hen > > --------------------------------------------------------------------- > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org > For additional commands, e-mail: commons-dev-help@jakarta.apache.org > > ------=_Part_17789_23351644.1133662422217--