Re: Maven Optimism

From: Pierce T. Wetter III (pierc..winforces.com)
Date: Wed Jul 09 2008 - 14:20:58 EDT

  • Next message: Pierce T. Wetter III: "Re: Maven Optimism"

    >
    > Lets place the blame where the blame belongs and make a more honest
    > comparison. This is most NOT an Ant issue. It is a WOProject /
    > build philosophy issue. The duplication between .classpath and some
    > of the files in woproject/ are a deficiency in the woproject Ant
    > tasks in that they currently can't use what is in .classpath. Mike
    > is working on fixing this.

       Hmmm... That's interesting. It's very true that my main frustration
    has been that edits in Eclipse don't get reflected in the nightly
    build which is driven by Ant. Well, really there are 3 issues for me:

       1. Developer builds in Eclipse.
       2. Nightly build done in Ant.
       3. Production deployment ends up not matching because of Java/
    Extensions issues.

       Better Ant/Eclipse integration would fix #1/#2.

    >
    >
    > Now, what does maven do for this? Unless it is reading
    > the .classpath file, it also has to somehow, somewhere duplicate the
    > information that Eclipse uses. Duplication is duplication. And
    > will Eclipse update the Maven information in the pom.xml when a new
    > framework is added? When a new jar is added to the project? Or is
    > that all manual pom fiddling?

       maven works in reverse. I don't know anything about the Eclipse
    maven plugins yet, but I think that when you add dependencies to the
    pom, it generates an updated classpath for use with running/compiling
    in Eclipse. The upcoming m2eclipse plugin means you can edit the
    dependency in a GUI fairly efficiently. And unlike Eclipse's build
    path editor, using maven means it pulls in the dedpendencies of the
    dependencies as well. So actually slightly less duplication because
    you can say "hey, I need this framework", without having to know what
    that framework needs in turn.

    In other words, if I'm interpreting things correctly, you set
    dependencies in a different place in Eclipse for maven-based projects,
    with the end result being no duplication because it uses maven to
    generate the build path for you.

    >
    >
    > The rest of the patternsets are also not an Ant issue, but a design
    > philosophy in woproject (to not force a project layout). If you do
    > use a project layout, as Wonder does, these can easily be rendered
    > unnecessary.

       Yeah, same recipe same bread thing again. If you standardize on a
    layout, life gets easier.
    >
    >
    > Finally, build.properties:
    >
    > principalClass=
    > project.name=
    > customInfoPListContent=
    > eoAdaptorClassName=
    > webXML=
    > webXML_CustomContent=
    > classes.dir=
    >
    > If Maven does not use these and does not have a parallel system,
    > then it has less flexibility.

       However, sure, maven is much less "flexible" then Ant. You can call
    your "clean" target "trash" in Ant. Maven makes you call it "clean",
    with the theory that then anyone knows how to clean your projects
    without having to read any .xml files. Perhaps "clean" is a bad
    example, but with other Ant builds I've had to dive in and browse the
    targets to see whether the master target is "build", "all", "package",
    "deploy", etc.

       With all software design, the challenge is always flexibility vs.
    forcing the user to end up with a bunch of boilerplate. I always end
    up including my TestNG code in my master builds because I have no idea
    how to tell Ant not to include those files...

    > How would Maven handle it if the package name for the Application
    > were changed in Eclispe?

       Well, that would be a maven/Eclipse/wolifecycle-plugin integration
    issue, so I'm not sure. I'm not sure where it gets that information at
    the moment as its not specified in the pom. Oh, I remember, there's an
    Info.plist file. Which seems natural to me as a Cocoa programmer, but
    I guess WOProject must generate that for you from build.properties.

      Pierce



    This archive was generated by hypermail 2.0.0 : Wed Jul 09 2008 - 14:22:32 EDT