commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henri Yandell <flame...@gmail.com>
Subject Re: [all] Maven, help or hinderance?
Date Sun, 04 Dec 2005 01:53:29 GMT
On 12/3/05, Stephen Colebourne <scolebourne@btopenworld.com> 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 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.

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.

> 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.

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.

Hen

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message