Re: Maven Skepticism

From: Lachlan Deck (lachlan.dec..mail.com)
Date: Wed Jul 02 2008 - 22:39:10 EDT

  • Next message: Lachlan Deck: "Re: Maven Skepticism"

    On 03/07/2008, at 10:00 AM, Pierce T. Wetter III wrote:

    >>> I'm a big picture guy, so worrying about what folders should be
    >>> named is
    >>> way too much a detail to bother me.
    >>
    >> Sorry if I wasn't clear enough about that. I'm talking about more
    >> than
    >> the standard directory layout. Maven enforce some "best practices".
    >> If
    >> you don't like one of its "best practices" you will probably start
    >> criticizing Maven because it is difficult or impossible to do in a
    >> different way. It is not lack of flexibility. It is a proposed way to
    >> develop software.
    >
    > Hmm... That's interesting.
    >>
    >
    >> For example, if one of your tests don't pass, the build fails.
    >
    > Ah, but presumably if I'm using TestNG (and why wouldn't you, it
    > rocks), I could deal with
    > that by changing TestNG's config file. :-)

    Or, if need be see the FAQ
    http://maven.apache.org/general.html#skip-test

    >> You can't release a project if it has a SNAPSHOT
    >> (under development) version of a dependency. These kind of
    >> "restriction" seems like a huge problem for some people.
    >
    > That one seems weird.

    By release, Henrique, I assume, is talking about the release plugin...
    http://maven.apache.org/plugins/maven-release-plugin/
    http://maven.apache.org/plugins/maven-release-plugin/introduction.html

    which, in short, is a plugin allowing you to tag, branch, rollback
    your project(s).

    You can of course package up (and/or install) your project at any time
    as a snapshot.
    $ mvn package
    $ mvn install

    http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html

    Built in and various available plugins:
    http://maven.apache.org/plugins/index.html

    >> The examples have not do with the standard directory layout.
    >
    > Er, Typo? The examples were not done with the standard directory
    > layout?

    'The above examples have nothing to do..' is what I suspect Henrique
    was saying.

    >>> Now in addition to all that, Java has this whole issue with
    >>> classpaths that
    >>> sucks. Eclipse hides a lot of the pain and suffering from you, but
    >>> once you
    >>> do a deployment, surprise, you're missing foo.jar! So maven has
    >>> some kind of
    >>> magic for dealing with this as well, something I don't understand
    >>> yet.
    >>
    >> Dependency Management + Repository Managers = Magic.
    >
    > Or, in English, with Maven you can say "I'm using Apache Commons
    > Logging". Then instead of spending 20 minutes Googling for what the
    > latest version is, finding out that the .tar.gz version in corrupt
    > so you have to download the .zip version... rather mvn it will find
    > it and shove it into your ~/.m2 folder when it does the build.
    >
    > More importantly, when someone says "hey, we should use the never
    > version of commons-logging", the nightly build system will suck in
    > the updated files.

    Someone, e.g., you, changes this...

    <dependency>
            <artifactId>commons-logging</groupId>
            <groupId>commons-logging</groupId>
            <version>1.1</version>
    </dependency>

    to
    <dependency>
            <artifactId>commons-logging</groupId>
            <groupId>commons-logging</groupId>
            <version>1.1.1</version>
    </dependency>

    and saves the pom, commits it to (insert favourite repository here).

    You might, as a safeguard against that version of the artifact
    dropping from the public repo someday put a copy of it on your
    intranet repo.

    >>> But it might solve that annoying problem, hallelujah. But its not
    >>> clear to me if
    >>> I can setup the dependencies in a GUI with Eclipse or if I have to
    >>> edit the
    >>> pom.xml.
    >>
    >> Not often. There is no 1.0 plug-in for Maven integration with
    >> Eclipse.
    >> So, you can suspect that some features are missing. Both plug-ins
    >> (m2eclipse [2] and q4e [3]) have wizards to add dependencies to your
    >> project. But it doesn't work every time. There is no visual editor
    >> for
    >> the pom.xml. But the Eclipse XML Tools can help with the autocomplete
    >> feature.
    >
    > Can you use both or do you have to choose one or the other?

    Both can work together. Just depends if you're picky about where
    things get defined. But ... to answer your question, if you've edited
    it by hand you can still use the GUI afterwards to make further
    alterations, no problems.

    >>> So...lets say I want to buy into maven. Lets say I want to do the
    >>> absolute
    >>> minimum amount of pom.xml hacking (though GUI editing in eclipse
    >>> is ok). Are
    >>> those steps documented anywhere?
    >>
    >> The current Maven documentation to develop WebObjects applications
    >> was
    >> referenced in my first e-mail.
    >
    > Yeah, as I said I read that, but that seems to assume you're making
    > a new project rather then migrating an existing project to maven. Or
    > are you implying the best way to migrate an old project is to
    > generate a new project, then move the old project files into the new
    > locations? I could see that, though of course it would give the
    > source control system fits, so what I really need to do is make a
    > new Maven WebObjects application, then copy files from it to the old
    > project, and issue "svn mv" commands as appropriate until the old
    > project structure mirrors the new layout.

    My projects still use the FBL. The way I went about it was to start
    off by putting the pom.xml files next to the existing build.xml files.

    Naturally I need to finish off the documentation I started here which
    I'm doing bit by bit as I get a moment.
    http://wiki.objectstyle.org/confluence/display/WOL/Maven+Kicking+the+tyres+without+changing+your+project+structure

    Let me know if there's anything in particular that you need.

    >> I think everybody will be happy if you
    >> start using Maven and help us to write more documentation.
    >
    > Does asking dumb questions count as helping? :-)

    It might highlight something that hadn't previously been thought
    worthy of mention - or that just needs clearer explanation.

    > Ok, I'll see about writing a "Maven for Lazy Noobs" document if I
    > can get something working.

    >>> So its seems like I'm half right. WOLips & Wonder are migrating to
    >>> FBL. The
    >>> maven plugins have their own layout, and in Wonder use pom.xml
    >>> instructions
    >>> so that maven groks FBL. Presumably, I could look at the Wonder
    >>> sources
    >>> (when maven builds are working again) and come up with an fbl.xml
    >>> that I
    >>> could use in all my project pom.xml files. If I did that, I could
    >>> migrate to
    >>> maven with a minimum of fuss.
    >>
    >> Not so easy. Lachlan have described his problems while starting to
    >> use
    >> Maven on "WebObjects Nightly Builds and WOLips addition" thread
    >> (referenced by Andrus). Besides, as WOLips and Wonder was not
    >> developed with Jar dependencies in mind, you may find some
    >> bugs/restrictions. Lachlan have already fixed some of them.
    >
    > Er, I made it a point to read that entire thread. I think Lachlan
    > goes into less detail then you might think. :-)

    I'm currently building my frameworks as jars by using standard maven
    stuff (i.e., <packaging>jar</packaging>). So I assume what Henrique is
    alluding to is that I came across a bug in WOLips that prevented me
    from migrating at the time.

    The two main hurdles (were):
    1) a WOLips bug that didn't recognise resources (e.g., EOModels,
    compoonents, etc) within a jar (even the apple jar frameworks). i.e.,
    it's assumption was that frameworks were *.framework bundles. So
    Andrew Lindesay and I worked to resolve that (http://issues.objectstyle.org/jira/browse/WOL-762
    )

    2) a woproject-maven bug (fixed by Henrique) as documented in the
    2.0.15 announcement.

    with regards,

    --
    

    Lachlan Deck



    This archive was generated by hypermail 2.0.0 : Wed Jul 02 2008 - 22:40:13 EDT