Re: Maven Optimism

From: Chuck Hill (chil..lobal-village.net)
Date: Wed Jul 09 2008 - 13:06:30 EDT

  • Next message: Anjo Krank: "Re: Maven Optimism"

    Hi Pierce,

    On Jul 9, 2008, at 2:50 AM, Pierce T. Wetter III wrote:
    >>>
    >>> To give you some examples, for the current Wonder Ant builds,
    >>> between build.xml files, generic.xml, build.properties
    >>> files, .classpath and .patternset files, there are 5320 lines of
    >>> build configuration information in the current Wonder build. The
    >>> equivalent pom files are 2447 lines, which is not only more
    >>> efficient, but includes more information to help avoid the
    >>> jarmeggedon/jarhell problem.
    >>
    >> Rubbish.
    >>
    >> First, the build files are *way* lighter:
    >
    > ....Anjo counts the lines of xml in Build/build/*.xml...
    >>
    >>
    >> These 1500 lines build *all* of Wonder in the way you specify, with
    >> the values you specify and the order you specify. *And* they allow
    >> you to specify your own builds with just a build property and a
    >> symlink to a build file. You could also use includes or or add your
    >> own customizations, but the tasks they do are very light.
    >
    > I may have miscounted by overcounting the symlinks to build.xml
    > though as I didn't notice those but I think you're undercounting by
    > only looking at Build/build/*.xml.
    >
    > I'm using this as a measure:
    >
    > wc -l `find . -name "build.xml" -print` Build/build/build-*.xml
    > Build/build/generic.xml `find . -name "build.properties" -print`
    > `find . -name "*.patternset" -print` `find . -name ".classpath" -
    > print`

    > Because the problem as I've found with Ant is that the build
    > information is in all of those files, not just build.xml.

    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.

    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?

    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.

    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. How would Maven handle it if the package
    name for the Application were changed in Eclispe?

    Chuck

    > This makes it easier to use a single generic Ant build file, but to
    > some extent that's the whole point of maven in my mind. With Ant,
    > everything is so bloody explicit that you end up creating a sort of
    > virtual maven via Wonder's generic.xml.
    >
    > To quote from "generic.xml":
    >
    > 2) to build your own projects that have the same layout as a wonder
    > project
    >
    > So mvn/Wonder have the same approach. Standardize on a layout, so
    > that you can use the same build methodology everywhere. You use the
    > same recipe you get the same bread.
    >
    > But I have to say, the ant build files are very complicated to
    > understand compared to the pom.xml files. In the past, I've found
    > that I end up having to grok all 1300 lines of Build/build/build.xml
    > and Build/build/generic.xml in order to debug the build of one of my
    > projects.
    >
    >>
    >> Second, the individual build files build way more projects:
    >>
    >> macbook:Wonder ak$ find . -name build.xml|wc
    >> 67 67 2775
    >> macbook:Wonder ak$ find . -name pom.xml|wc
    >> 56 56 2121
    >
    > You're looking at what you have, but I've rewritten all of those and
    > added new ones. I have files to build nearly everything in Wonder on
    > my system:
    >
    > sierramadre:Wonder pierce$ find . -name pom.xml | wc
    > 68 68 2440
    >
    >>
    >> Thirdly from what I've seen, someone needs to change all these
    >> files whenever we bump a version. All of Ulrichs commits so far
    >> where these xml fixes. All *I* need to do is set one property.
    >
    > I'm using a property in my pom.xml versions as well. So changing
    > all those files isn't really necessary, I can change the version by
    > changing the master pom.xml, same as you can. Eventually, I'll move
    > all the jar references up to the master pom, which will save me a
    > line per reference, and standardize the versions used.
    >
    >>
    >>
    >> Fourth, adding a project typically requires five lines in Build/
    >> build/build.xml to add it to the correct group and some props. I
    >> might consider moving these props from the build file to a
    >> build.properties and making Build/build/build.xml only specify the
    >> inter-related deps.
    >
    > Except you have to add the build dependencies somewhere as well,
    > which if you want to compare apples/oranges, you really have to
    > count right? You also have to count the information in
    > build.properties. The information in the pom.xml file for a new
    > project without dependencies is more then 5 lines, its like 10
    > lines, but 5 of those name the project so you can reference it
    > elsewhere and the other 5 reference the super-pom.
    >
    >>
    >>
    >> I'll grant you one point for the commons-logging versions, but I
    >> use neither ERJGroups or EROpenID. If I were and I'd be bothered,
    >> I'd figure out a way to keep them using only one.
    >>
    >>
    >
    > It's not just that jar. WO uses commons-logging as well. The real
    > point here is that managing jar dependencies sucks. I know you feel
    > criticized but you shouldn't take it personal because I'm talking
    > about Wonder as my real point is that Wonder, which is widely used,
    > and considered pretty stable, has some jar dependency issues. The
    > solution to the jar problem that Wonder uses is the ERJars framework
    > for common jars, and Libraries directories for unique jars, but that
    > doesn't really solve the problem unless someone with Obsessive-
    > Compulsive-Disorder dedicates their life to keeping ERJars in sync.
    > Even then, what if you want some frameworks and not others from
    > Wonder, or you need the same (but newer version) jar in one of your
    > applications.
    >
    > The maven solution is to document the dependencies, and setup a
    > whole bunch of infrastructure in order to be able to compute all
    > that stuff on the fly.
    >
    > Again, you use the same recipe you get the same bread;
    > conceptually, ERJars functions as a maven repository, just one
    > manually maintained.
    >
    > Having had to fight with a whole bunch of jar dependency issues in
    > production recently, I'm leaning more towards the maven way; as
    > opposed to trusting that every engineer will dutifully scour all the
    > other Libraries directories in all the other projects to see what's
    > needed where. Or even that I'll remember to push the missing jar
    > into production.
    >
    >>
    >>
    >> So far we've seen that maven is neither more terse nor more
    >> powerful (at least in a way that would mean something to me).
    >
    >
    > I think maven makes a reasonable attempt to solve a really, really
    > annoying problem.
    >
    > As far as terseness goes, perhaps that's not the right measure,
    > but generic.xml gives me the freaking willies, while pom.xml seems
    > stunningly obvious. I mean I really, really detest Ant build files.
    > I'd actually prefer regular make files.
    >
    >
    >>
    >> The other issues I have with it is that I actually *need* the
    >> flexibility in deployment structure. In some projects I *don't*
    >> want all-embedded builds as that stuff goes out of hand with 7
    >> apps*all the frameworks. The resulting release tops 250M. So I want
    >> some of them embed only some jars. Show me how this works with
    >> maven *without* writing any "goals" or "mojos".
    >
    > Well, now you're bottoming out my maven knowledge, as I'm not quite
    > sure what you're complaining about.
    >
    >>
    >>
    >> So in summary, maven may or may not be nice. But I've been building
    >> Wonder with the build files for 7 years now and they haven't really
    >> changed a lot in this time. They do the roughly the same as some
    >> 20MB tool chain where you *still* have to write java plugins for.
    >
    > And I have to maintain a build that's based on some stale snapshot
    > of the Wonder build files, and given a choice between grokking
    > generic.xml and or throwing it out and learning maven, I'm leaning
    > towards Maven, because its sucked so far. Of course, the latest
    > Wonder generic.xml looks a lot cleaner then what I have now, so
    > that's not necessarily a fair criticism. But maybe it is, because I
    > would never have dived into Wonder to tweak the Ant builds, but
    > tweaking the Maven builds was pretty simple.
    >
    > But as I keep saying, you use the same recipe you get the same
    > bread. The Wonder Ant build and the Maven build at the end of the
    > day have to do the same steps and need the same information. Ant,
    > being more explicit, ends up pushing you towards a generic.xml type
    > solution, where every step in the build is spelled out explicitly,
    > but a certain folder layout is assumed, and certain things are
    > stored in external files. That way, you can use the same Ant build
    > script over and over.
    >
    > Maven, being more implicit, ends up pulling the equivalent of
    > generic.xml into these plugin definitions based on the assumption
    > that all WO framework projects have to be built the same way for all
    > developers. That leaves the project specific information to be
    > specified somewhere like the project name and dependencies. Which
    > goes in one place, the pom.xml.
    >
    > So at the end of the day, to use Wonder's generic.xml, you have to
    > setup your folder structure in a certain way and put certain
    > information in .classpath, .patternset, and .properties files. To
    > use maven, you have to setup your folder structure in a certain way
    > and put that same information in pom.xml. At the system level you
    > have to think of Ant as Ant plus the generic.xml you're using, and
    > at that point, Ant+Wonder Build Scripts == Maven. Maven just goes on
    > to leverage the information in the pom in other ways.
    >
    > This title of this post is "Maven Optimism", following up from
    > "Maven Skepticism". I'm still a long way from being a maven expert,
    > but I've sort of refused to become an Ant expert. But so far, I'm a
    > lot more optimistic about being able to use Maven effectively. I
    > think it brings a lot to the table, and solves some tough
    > development issues.
    >
    > Pierce
    > _______________________________________________
    > Do not post admin requests to the list. They will be ignored.
    > Webobjects-dev mailing list (Webobjects-de..ists.apple.com)
    > Help/Unsubscribe/Update your Subscription:
    > http://lists.apple.com/mailman/options/webobjects-dev/chill%40global-village.net
    >
    > This email sent to chil..lobal-village.net
    >

    -- 
    

    Practical WebObjects - for developers who want to increase their overall knowledge of WebObjects or who are trying to solve specific problems. http://www.global-village.net/products/practical_webobjects



    This archive was generated by hypermail 2.0.0 : Wed Jul 09 2008 - 13:07:42 EDT