Making Maven less "curse-worthy" (Porter’s terse branch)

Brett has some good ideas to create a newer POM format that relies more on XML attributes, I’m also thinking about different representation formats. Why not start thinking about allowing people to innovate and support even leaner alternative formats like YAML? Eric wrote something of a preprocessor, but why not open up the code that reads the model and make it pluggable? Isn’t this the point of using something like Plexus? And, even if it doesn’t fall into line with what Maven’s leadership wants, wouldn’t it make sense to allow someone to scratch this particular itch.

Just proposing the idea of pluggable POM parsers provokes general disdain. Jason would never want to allow “Scripting” or “Ruby-specific” formats for POMs as it would be a “disaster”. (Nevermind YAML is a hierarchical data structure that has little to do with scripting. It can be parsed in C, Java, Python, Ruby, Perl, Javascript.) Michael McCallum doesn’t want to allow POM innovation because allowing for POM innovation would make it more difficult to know if the people you were hiring really knew what a POM was. (Open source driven by corporate HR, that’s exciting!) Several arguments about how allowing for new POM formats with break Universal Understanding.

But the discussion is interesting… there’s little discussion of Brett’s code. The thing to realize about open source development lists is that maybe something like 25% of the subscribers have ever even bothered to checkout and build the code, the remaining 75% of readers are there to feel important. In the interest of contributing to the discussion, here’s some feedback for Brett.

Feedback on Brett’s Branch

Brett’s changes start in DefaultMavenProjectBuilder he introduces a ModelReader which takes care of reading both 4.0.0 and 4.1.0 models. Instead of handling the Xpp3 parser errors, this new ModelReader throws a import if there is a problem parsing some POM XML.

1. ModelReader makes sense, and it’s a change for the better to move remove the code to check the model version from the DefaultMavenProjectBuilder. To see what this class used to do, look at DefaultMavenProjectBuilder (from trunk) and search for “checkModelVersion”. Yikes, good move to get rid of that.

2. Make ModelReader an interface, move the current ModelReader to DefaultModelReader. Even though the majority of Maven overlords don’t want people to innovate wrt POM format, there’s no reason to close the door on the idea entirely.

3. (I know this won’t happen) but it would be useful if DefaultMavenProjectBuilder didn’t have to catch an XML parsing exception. Maybe a ModelReadException that contains the underlying exception that caused the problem.

4. (I also know this won’t happen) move everything related to XML parsing (“ReaderFactory.newXmlReader(file)”) into the DefaultModelReader implementation.

In general, I think Brett’s terse branch is a move in the right direction, it would make the process of customizing the format easier, and starts to tackle the problem of tight coupling between the Modello parsers and Maven core.

There is hope (from Atlassian)

Don Brown chimed in:

“Whether an attribute-based design is “proper” is a less important question than what makes Maven more usable. Form should follow function. What users care about is more readable POMs, less typing, and less clutter. I’ve been really impressed with the Maven team adopting a more programmatic approach to Maven recently, and this change will go a long way to making Maven more usable and less curse-worthy.”

Couldn’t have said it better, “what users care about is more readable POMs, less typing, and less clutter”.