commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Cooper <mart...@apache.org>
Subject Re: [all] Maven, help or hinderance?
Date Sun, 04 Dec 2005 02:13:42 GMT
On 12/3/05, Henri Yandell <flamefew@gmail.com> wrote:
>
> 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'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 for
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 to
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
>
>

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