Sunday, April 29, 2007

My Goals for the Summer

Make Maven pretty - the end.

"Maven is ugly" I think that is the complaint I hear most often: it takes too much XML to do anything. I love Maven, really, but it's difficult to fall in love with, especially for your average developer, because it is so unpretty compared to the slim hotties like Rake or Ant. Despite the face, Maven has a good heart, will stick with you forever, and makes a mean home-made dish - like the old song goes, "If you want to be happy for the rest of your life you got to make an ugly woman your wife..."

But, just like everyone else, I want both - looks and a faithful personality to boot.

So, for example, look at the relatively simple task of creating a project with an integration test and then cleaning it up:
<project xmlns="http://maven.apache.org/POM/4.0.0" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>com.training.plugins</groupId>
<artifactId>maven-zip-plugin</artifactId>
<packaging>maven-plugin</packaging>
<name>Maven Zip Packaging Plugin</name>
<version>1.0-SNAPSHOT</version>

<dependencies>
<dependency>
<groupId>org.apache.maven</groupId>
<artifactId>maven-plugin-api</artifactId>
<version>2.0.4</version>
</dependency>
<dependency>
<groupId>org.codehaus.plexus</groupId>
<artifactId>plexus-archiver</artifactId>
<version>1.0-alpha-6</version>
</dependency>
</dependencies>

<build>
<plugins>
<plugin>
<artifactId>maven-invoker-plugin</artifactId>
<executions>
<execution>
<id>zip-packaging-test</id>
<phase>integration-test</phase>
<goals>
<goal>run</goal>
</goals>
</execution>
<execution>
<id>zip-packaging-clean</id>
<phase>pre-clean</phase>
<goals>
<goal>run</goal>
</goals>
<configuration>
<goals>
<goal>clean</goal>
</goals>
</configuration>
</execution>
</executions>
</plugin>
<plugin>
<artifactId>maven-clean-plugin</artifactId>
<configuration>
<verbose>true</verbose>
<filesets>
<fileset>
<directory>src/projects</directory>
<includes>
<include>**/build.log</include>
</includes>
</fileset>
</filesets>
</configuration>
</plugin>
</plugins>
</build>
</project>
66 lines of <XML></XML> Here is the same information as above, in a 15-line pseudo-YAML, truncated form.
modelVersion=4.0.0
coordinate=com.training.plugins:maven-zip-plugin:1.0-SNAPSHOT:maven-plugin
name=Maven Zip Packaging Plugin
depends=[
org.apache.maven:maven-plugin-api:2.0.4,
org.codehaus.plexus:plexus-archiver:1.0-alpha-6 ]

build:
invoker:
execute run on integration-test => zip-packaging-test
execute run on pre-clean => zip-packaging-clean
goals=[clean]
clean:
verbose=true
filesets=[{directory=src/projects,includes=[**/build.log]}]
Now, don't get me wrong. I'm not going to try and make the POM understand YAML. The point is - and this is an important point - the POM above does a lot of work with very little information. The problem is that Maven doesn't do a good job showing its inner beauty - its true simplicity - because its outside is fugly as hell. Maven's configuration is complex to keep its core simple... almost to a fault. Maven has a beautiful soul and a butt-ugly face. It's time for a teen-movie make-over - no more glasses, no more ponytail.

That's my goal for this summer... to make it a little bit more shallow, a little bit more trashy - just enough to turn some heads.

Wednesday, April 25, 2007

Free Maven Book!

Well, it's finally out. The free web version of Maven: The Definitive Guide. This book is consistently under development, so feel free to make suggestions. We also have a deal with O'Reilly, so look for it soon in PDF and dead-tree formats!

    -- Your Good Friends at Sonatype

Wednesday, April 18, 2007

Common Misconceptions About Maven

There are plenty of build tools out there, why switch to Maven? Or more to the point, why bother investigating it at all? Here are a couple things you should know about the project you love to hate.

The Importance of Modularity

I will play my cards right now, and declare that the build infrastructure should be considered at least as important as the project architecture itself. Let me say that again - the architecture that your company has spent millions of dollars developing (or your brain has spent millions of cells imagining) is at best half as important as the infrastructure in place to build that code. Looked at another way, it is almost inevitable. Great infrastructures are measured - in part - by their modularity - the ability for work to be divided, portions to be extended, and other portions to be re-used, without effecting the rest of the code or API. But this flexibility is at the mercy of the tools able to bring all of those modular pieces together. I have debated before that a software architect's role is not to "design projects" but to "maintain the integrity of a software system". If this requires groovy designs, so be it, but it just as often requires other things, such as coherent project structures, naming conventions, unit and integration testing, inter/intra-team communications via documentations, and ease of deployment. This is what Maven strives to provide.

Maven is not a replacement for Ant

Actually, the core Maven team actively pushes the usage of Ant, and even took the liberty of embedding Ant into the Maven core. This is not a nefarious plot to steal Ant users - but rather because we all understand two things: 1) people like Ant, and 2) it's useful. You can think of Maven as a declarative jacket over Ant (it's not), if you like, the same way that Ant is a procedural/configurable jacket over a bunch of Java classes. Man, will the battle ever end?

Rake is not Made for the Enterprise

Enterprise development, almost by definition, are efforts requiring many, many people working together (only about 20% of which are actually developers). Rake (Ruby Make) is great - I love it, and I freely admit to being a Ruby freak. With that said, it has no place in an enterprise environment - simply by it's nature. Enterprise environments are not populated by the "best of the best", even for a place like Google. No, there are a few great developers, a field of mediocre, and a few horrible developers. Enterprise environments are set up to hedge their bets - that the bad ones will, by oversight or lack of access, be both traceable as well as minimize their damage. This has the unfortunate side-effect of binding the hands of great developers.

Side story: I once asked for $50,000 to start a coffee shop from a man who makes $1 million a month. He said absolutely, emphatically, unequivocally "NO". Not because he didn't like me, or didn't trust me, or wanted me to fail. All he saw was risk. If something horrible went wrong, like the building burned down, he might be sued for millions (regardless of what kind of contracts we had). On the flip side, if I had the most successful coffee shop in 10 states, he might only make an extra $250,000 - the sum he makes in a week.

The point being this: large organizations and wealthy individuals do not think the same as poor folk like you and I - nor can they afford to. Suppressing risks as well as benefits is the tradeoff - a fact that you can see by looking at the payscale. The great programmers may be 10 times more productive, but probably get paid only slightly more than the worst. Back to Ruby. At any point a ruby script can be modified, turned to the twisted will of a well-meaning developer. You can overload anything, at any time. And for every genius who knows what he's doing, there are 20 who think they do, and fuck things up. As I've been known to say, "Different tools for different jobs. That has not changed, and never will." You can't build an enterprise app in Rails (or a build system in Ruby)... and you're a goddamn fool if you try to use Java to write your grandma's homepage. The Ameritrade trading system, for example, could never survive as a Rails app. MediaWiki, however, could.

Maven strikes a decent medium in the same way that Enterprise executives do. It suppresses the risks of a free-for-all (Rake) at the loss of a little agility. This brings the question then: how agile do you really need your build system to be?

Sonatype - Professional Maven

Maven has long been without any great commercial support (beyond that "other company" - that mainly goes after top 100 accounts). In spite of this, Maven has a thriving community built on an active volunteer army of coders. However, Maven is also in danger of growing into somewhat of a clusterfuck (ever tried to actually use Archiva?).

In an attempt to bring sanity and some more full-time eyes to this, myself (Eric Redmond), Maven founder Jason van Zyl, Maven commitors John Casey, Andrew Williams, Kenney Westerhof, and Eirik Bjørsnøs, as well as Aldrin Leal and Rahul Thakur have been working these past few months to create Sonatype for commercial support of Maven, Maven training, and better documentation.

Monday, April 2, 2007

Maven 2.0.6 Released

Announcement! Apache Maven 2.0.6 has been released, 6 weeks after 2.0.5. The team is discussing a 6 week release schedule to help squeeze out a lot of the little bugs that have plagued Maven 2 in the past.