Matt RaibleMatt Raible is a Web Architecture Consultant specializing in open source frameworks.

10+ YEARS


Over 10 years ago, I wrote my first blog post. Since then, I've authored books, had kids, traveled the world, found Trish and blogged about it all.

Maven Integration for Eclipse

If you're a Maven user and like Eclipse, you might want to checkout the new Maven Integration Plugin for Eclipse 0.9.0. Euxx has a couple blog posts talking about the new features - looks like pretty cool stuff to me.

The second feature is especially cool. If your dependencies supply SCM information - you can import the project from its source control system. Maven may have warts, but it also has incredible potential.

Posted in Java at Mar 12 2008, 04:22:43 PM MDT 2 Comments

Maven now supports attributes in pom.xml?!

In December 2005, I asked Is it possible to make pom.xml simpler?.

After seeing what the Spring Developers have done to simplify Spring context files, I can't help but think the same thing is possible for Maven 2's pom.xml. Is it possible to add namespaces and make something like the following possible?

Before:

    <dependency> 
      <groupId>springframework</groupId> 
      <artifactId>spring</artifactId> 
      <version>1.2.6</version> 
    </dependency> 

After:

<dep:artifact name="org/springframework/spring" version="1.2.6"/>

Or just allow attributes to make things a bit cleaner?

<dependency groupId="org.springframework" artifactId="spring" version="1.2.6"/>

At that time, the general response was "That's how Maven works. It's a matter of taste. You'll get used to it." It's been two years and sure, I'm used to it, but I'd still rather write less XML. That's why I was particularly pleased to see Brett Porter's write Maven now supports condensed POMs using attributes:

The issue is being tracked under MNG-3397.

The result is that something like this:

<dependency>
  <groupId>junit</groupId>
  <artifactId>junit</artifactId>
  <version>3.8.1</version>
  <scope>test</scope>
</dependency>
<dependency>
  <groupId>easymock</groupId>
  <artifactId>easymock</artifactId>
  <version>1.2_Java1.3</version>
  <scope>test</scope>
</dependency>
...

Halves in length to something like this:

<dependency groupId="junit" artifactId="junit" version="3.8.1" scope="test"/>
<dependency groupId="easymock" artifactId="easymock" version="1.2_Java1.3" scope="test"/>
...

Now that wasn't so hard was it? ;-)

Posted in Java at Feb 11 2008, 03:45:57 PM MST 4 Comments

Building a Better Maven with Ant

It looks like the Ant folks are thinking of building a better Maven.

I see many developers adopt Maven because they want a build system able to provide common features with no effort. Most of them don't want to spend much time writing an Ant script, or have seen or heard that maintaining Ant build scripts is troublesome. So they choose to use Maven only because it's easy to use for common use cases: install, write a simple pom of a few lines or generate it using an archetype, and you're ready to compile, test and package your new project following the Maven standard structure. They also get dependency management for free, and with only a few more effort they have multi module builds, and some nice features like code analysis, coverage, and a set of report gathered in a web site. That's really nice and that's what I like about Maven.

But Maven suffers from a lack of flexibility and robustness IMHO. And later the same people who first adopted Maven because of its perceived ease of use become frustrated when they need to tweek the system to their own needs or don't understand how the release plugin work. Then some of them go back to Ant, first having to go through a sometimes painful road to describe their whole build system in xml, especially if they aren't Ant experts. Others try to use new build tools like raven, buildr or others.

I really like Ant, and think it is a very good basis for robust and flexible build systems. People with enough knowledge of Ant can write very good build systems, testable, maintainable and adaptable. But you need to get your hands dirty, and you need to get a good knowledge of some of the mechanisms which can make an Ant based build system manageable: import, scripts and scriptdef, macrodef, presetdef, and so on. [Read More]

What do you think - is this a good idea?

I agree that Maven has its warts, but I don't think it's that bad. I've also heard that Maven has been successfully implemented at large companyies like eBay, Intuit and E*Trade[1]. Is the "Maven sucks" meme largely something that exists in the blogosphere, but not in the real world?

I think the biggest benefit of Maven is dependency management. I think it makes your code more modular and easier to build. Rather than having a monolithic source-code tree that depends on itself being built in a certain order, you can have individual modules that pull dependencies from a central location. This can be done with Maven's Ant Tasks as well. I don't see a problem with building a better Maven with Ant, but to try and build a better Central Repository sounds like a nightmare to me. The current repository has been improved for years and is much better than it was a couple years ago. That being said, I would love to see somebody build a more accurate Central Repository. Ideally, it'd be done sometime next week. ;-)

[1] I could be wrong about these companies. If you're a developer at one of these companies, please confirm or deny. Any comments on Maven's success at these companies would be great as well.

Update: Speaking of Maven, there's an interesting comment on a Javalobby post I wrote:

With all the critical remarks the Maven project is receiving, wouldn't it be time for some Maven project lead to step up and explain the team's position? Or is it completely deaf to the sentiments? How many builds have to fail, how much more headaches are needed before others start their own version of Maven and do it the right way (like Don [Brown])?

Seems like an excellent question to me. Guys?

Posted in Java at Feb 11 2008, 02:07:12 PM MST 18 Comments

Maven 2 Archetypes get a much needed improvement

Yesterday, a new version of the Maven Archetype Plugin was released. This release incorporates many of the improvements that were developed in a different project - code named "Archetype NG". The two major improvements are 1) you only have to use "mvn archetype:create" now and 2) you can create archetypes from existing projects.

I haven't tried #2, but #1 seems to work pretty well (especially since AppFuse archetypes are the first 9 ;-)).

[Read More]

Posted in Java at Feb 09 2008, 03:20:00 PM MST 15 Comments

RE: Why Grails doesn't use Maven

Graeme Rocher's in Why Grails doesn't use Maven:

In his post entitled "Grails - The Good, The Bad and the Ugly", Jonas has some nice praise for Grails, his main beef is that it is not built on Maven.

So I wanted to clarify why exactly we chose not use Maven (by default) and the explanation is there for all to see in Jonas' first example of creating a Grails application vs creating a Maven project:

Instead of

grails create-app name

could be just

mvn archetype:create -U\
-DarchetypeGroupId=net.liftweb\
-DarchetypeArtifactId=lift-archetype-blank\
-DarchetypeVersion=0.4\
-DremoteRepositories=http://scala-tools.org/repo-releases\
-DgroupId=your.proj.gid -DartifactId=your-proj-id

My goodness, what a mouthful the Maven example is. There is a common acronym in the open source world called RTFM (read the *ing manual), when a user asks a question on a mailing list and the "experts" respond by pointing them to the place in the manual.

I think Maven's biggest problems are 1) poor metadata in the central repository and 2) the source of metadata in projects (pom.xml).

I believe #1 can be fixed if the Maven guys allow dependencies to be fixed based on user feedback. It's also gotten a lot better in recent years. In reality, maintaining transitive dependencies is hard and I believe Maven has done a good job. In reality, they're the only ones that slurp up transitive dependencies, so the only other option is to maintain the dependencies yourself.

To fix #2, I think the problem is mainly XML and the verboseness of the elements-only pom.xml that Maven requires. Most of the contents of a pom.xml are either dependencies, plugins or exclusions/variances of Maven's conventions. What if Maven's metadata was pluggable? What if XML was only one option? What if you could write a pom.groovy and describe your entire build process in 5 lines instead of 500? That would be very cool.

I'm still a Maven fan, mostly because it's greatly simplified the maintenance of and releasing of AppFuse. When I do GWT, Seam or Grails development in the future, you can be sure I'll try to use Maven to do the development. Why? Because I've learned how to use it and I don't feel the pain that so many others talk about. I also think it really shines on really large projects (builds that produce 30+ WARs for example). An Ant-based system on really large projects can become quite burdensome and difficult to maintain. Not only that, but it's very difficult to maintain a modular build system (where you can build/test/deploy a single WAR) with Ant. In my experience, really large Ant-based systems take forever to process that everything is up-to-date whereas Maven systems depend on each other and require you to keep them up to date. Sure it requires you to be smarter and run "mvn install" on your subprojects, but I'd rather do that than wait 5 minutes for Ant to process everything just to run a test.

You might remember that the main reason I used to prefer Ant over Maven was speed. That was in Maven 1 days. With Maven 2, speed is no longer a problem and I've found it much easier to run "mvn jetty:run" than "ant deploy" and wait for Tomcat to restart. IMO, the perfect development environment is one were you can run a command-line command (or use your IDE to start the server) and code away without worrying about restarts. Seam and Grails offer this environment, but it's unlikely your entire organization is going to use standardize on those frameworks and not have anything else. I think Maven and the Maven Jetty Plugin offer a nice alternative for the rest of those applications.

Posted in Java at Jan 16 2008, 10:49:35 AM MST 11 Comments

Upgrading AppFuse to Spring 2.5

Last night, I spent a few minutes upgrading AppFuse to Spring 2.5 RC1. According to InfoQ, Spring 2.5 is a drop-in upgrade for Spring 2.0. However, if you're using Maven, it's not quite that easy. The good news is it is easy, you just need to change your pom.xml a bit. The steps I used to upgrade AppFuse are listed below:

  • Add a repository for Spring's milestone releases:
    <repository>
        <id>spring-milestone</id>
        <url>http://s3.amazonaws.com/maven.springframework.org/milestone</url>
    </repository>
    
  • Change artifactId of "spring-mock" to be "spring-test".
  • Change version to be 2.5-rc1.

At this point, if you're using "spring" as your artifactId (instead of the smaller fine-grained dependencies), you'll likely get the following error in a Spring MVC application:

java.lang.NoClassDefFoundError: 
org/springframework/web/servlet/handler/AbstractUrlHandlerMapping

This happens because Spring MVC is no longer included in the uber spring.jar. You'll need to add a dependency on "spring-webmvc" to solve this problem. Unfortunately, this JAR is dependent on the fine-grained modules, so you may have to modify your pom.xml to depend on the fine-grained modules - or exclude them all from spring-webmvc.

The good news is Spring has excluded all the invalid commons-logging dependencies for you so you don't have to anymore.

After getting all the dependencies straightened out - I ran the integration tests:

org.springframework.beans.NotReadablePropertyException: Invalid property 
'fileUpload' of bean class [org.appfuse.webapp.controller.FileUpload]: Bean 
property 'fileUpload' is not readable or has an invalid getter method: Does the 
return type of the getter match the parameter type of the setter?

Looking at uploadForm.jsp, I'm guessing the problem happens because of the following code:

<spring:bind path="fileUpload.file">
<input type="file" name="file" id="file" class="file medium" value="<c:out value="${status.value}"/>"/>
</spring:bind>

Confirmed - changing the "path" attribute to "file" fixes the problem. I also found out that setting the "value" on an <input type="file"> doesn't work, so wrapping the field with <spring:bind> doesn't make a whole lot of sense anyway.

To conclude, it doesn't look like the first release candidate of Spring 2.5 is exactly a drop-in upgrade for Spring 2.0, but it's pretty darn close. I'm sure by the time it's released, it will be. I'd encourage you to try 2.5 in your Spring-dependent projects to see if you find any issues.

Update: I was successfully able to migrate AppFuse from using the uber JAR to fine-grained JARs. However, I ran into a couple issues in the process. The first is that even though I'm including spring-aop in the appfuse-service module, it's not pulled in for the web frameworks (which depend on appfuse-service). Explicitly declaring spring-aop as a dependency for the appfuse-web module fixes this. Secondly, I had to modify my Acegi Security exclusions so it wouldn't include dependencies that no longer exist in 2.5.

<dependency>
    <groupId>org.acegisecurity</groupId>
    <artifactId>acegi-security-tiger</artifactId>
    <version>${acegi.version}</version>
    <exclusions>
        <exclusion>
            <groupId>org.springframework</groupId>
            <artifactId>spring-dao</artifactId>
        </exclusion>
        <exclusion>
            <groupId>org.springframework</groupId>
            <artifactId>spring-jdbc</artifactId>
        </exclusion>
        <exclusion>
            <groupId>org.springframework</groupId>
            <artifactId>spring-remoting</artifactId>
        </exclusion>
        <exclusion>
            <groupId>org.springframework</groupId>
            <artifactId>spring-support</artifactId>
        </exclusion>
    </exclusions>
</dependency>

Posted in Java at Nov 07 2007, 08:27:20 AM MST 3 Comments

Flex and Grails Made Easy

I love how easy it is to start new projects these days. It was very difficult when I started creating AppFuse way back in 2002. We've come a long way baby!

Here's a couple of easy ways to get started with Flex and Grails:

I hope to develop with Flex, Grails, GWT or YUI + Struts 2 in the next 6 months. These seem like the most exciting technologies for Java web development in 2008.

Posted in Java at Nov 01 2007, 11:00:38 PM MDT 5 Comments

Maven Meetup in San Francisco tomorrow (Tuesday)

If you live in the Bay Area and you're interested in talking with the inventors of Maven and/or XWiki, you should checkout the XWiki + Maven meetup at Terracotta's HQ. Java Open Source gurus Vincent Massol and Jason van Zyl will be there - sounds like a fun event!

Posted in Java at Oct 08 2007, 10:55:41 PM MDT 1 Comment

Live Coding for 4 Days Straight

Last week I had an interesting 4-day consulting gig for a client in Boulder. I was supposed to fly out to Connecticut to deliver a training course, but it got rescheduled due to the 45-day Vendor Approval Process I need to go through. The client in Boulder wanted me to come out and do an architectural assessment and provide recommendations. Topics they were interested in: web tier (specifically Spring MVC), Security, Ajax integration, build process, web services and localization. I've done this kind of before with Virtuas, but this time was different. With Virtuas, I'd do 5-days worth of presentations on just about anything the customer wanted. For example, checkout this agenda for a client in NY last year.

With the company in Boulder, I delivered zero presentations. Instead, everything we talked about and coded was hands-on. On Tuesday, we started out by discussing their application and some issues they were having. They'd done a lot of customization to Spring MVC and had managed to eliminate all the XML needed when adding new controllers and views. I spent 3-4 hours that day with 2 of their engineers finalizing and implementing their convention-over-configuration rules. On Wednesday, I helped them implement Acegi Security into their application. This was interesting because they didn't have any security mechanism and we had to implement Acegi from scratch and then tie it into their backend (using a custom AuthenticationProvider). We also integrated i18n so all messages were retrieved from their database.

On Thursday, we configured Ant to run their tests and wrote some tests for their controllers. As part of this process, I showed them how to use jMock and EasyMock and tried to explain the benefits of using Spring IoC (which they still aren't sold on). On Friday, we integrated Selenium into their build process and wrote a few tests using Selenium's Java support. In the afternoon, I showed them how they might use Scriptaculous and Prototype to Ajax-enable some features in their application.

Doing all the "live coding" on someone else's machine (with 5 developer's watching) was a bit nerve wracking. However, thanks to Cenqua's FishEye tool, I was able to search AppFuse and AppFuse Light's SVN repositories for code snippets and examples. While I knew how to do much of the stuff we covered, FishEye and Google bailed me out when I didn't. About halfway through, I realized that I don't keep a lot of my knowledge in my head. Instead, it's on this blog, or spread out on the web. I don't remember URLs anymore, all I remember are keywords. If I've read a blog post or article on the web, chances are I can find it again pretty easily with Google. Even though I store a lot of bookmarks in del.icio.us, I didn't use it all week. Remembering keywords is the new bookmark for me.

The whole week was an interesting exercise in "live coding." The whole team (6 or so) sat in a conference room all week and VNC'ed into the architect's box to do the work. We worked in Eclipse and used WTP to deploy/test things on Tomcat. The keyboard was passed around between developers at random and everyone got a chance to implement new features. I think the reason that everything worked so well was because the team was full of Senior Java Developers. Everyone learned from each other as they saw new shortcuts, keystrokes and ways or writing code. I don't know if this kind of thing will work in all development teams, but I'd encourage you to try it. It's a great way to share knowledge and educate the entire team on how a new module works.

Over the weekend, I received the following e-mail from one of the developers on the team:

Very nice to meet you this past week and get a chance to see firsthand the breadth and depth of your experience in web app frameworks and such. I believe due to your visit, we will be cranking happily along here very shortly. Everyone was quite happy with the results at the end of the day yesterday.

On a related note, if you're looking to hire an enthusiastic Web + Java Developer, please take a look at my resume or send me an e-mail. My current contract ends this month and I'm hoping to find something new to get me through the summer.

Posted in Java at May 24 2007, 01:50:30 PM MDT 1 Comment

Sonatype - a new company around Maven

From Jason van Zyl's Maven Diaries:

Sonatype Since my departure from Mergere I've been quietly and steadily working to help start a Maven related company that I'm proud to say I'm a part of. No grandiose launch, no marketing hype, no VCs, haven't talked to a single analyst, and we hope that you can actually understand what we do by looking at our website. The company's name is Sonatype and I'm finally happy with the people involved and the direction we're headed in. We are focused on facilitating the adoption of Maven through our partners network, providing training, and delivering Maven related products for software development.

Having two companies wrapped around Maven can't be a bad thing. However, let's hope Sonatype has some funding to pay folks to work on the project more, rather than other products that may or may not be successful.

Two things that could make this company very well liked in the open source community:

  • Clean up the Maven Repository: Add/delete/modify as requested by users. There's other projects using the repo now and even folks campaigning against Maven. If Maven folks are responsible for cleaning it up, they'll be heroes.
  • Provide repository statistics: A lot of open source projects like to track their download statistics. It's a metric for measuring success (in addition to mailing list traffic). If they move to a full Maven-based distribution model (like AppFuse is), there's no more statistics.

Are there other things you think Sonatype can do to make Maven easier to use and more successful?

Congrats to Neel, Jason, John, Kenney, Andrew, Eric and Eirik. I hope you succeed in your mission. I think w/o the VCs and the get-rich-quick folks, it should be a lot easier. Cash isn't always the key indicator of success - more often happiness and job satisfaction are.

Posted in Java at Apr 18 2007, 09:19:21 AM MDT Add a Comment