Raible Designs

Comprehensive Project Intelligence with Jason van Zyl

In this talk, Jason is going to talk about m2eclipse, Nexus, Hudson and Maven. On his Maven bullet-point, it says "The best is yet to come (and we'll fix a bunch of stuff)!"

m2eclipse
The m2eclipse plugin has improved greatly in the last 4 months - there's now 5 full-time developers working on it. If you use the m2eclipse plugin, you never have to leave the IDE for your Maven-related work. m2eclipse has a Configuration Framework that turns Maven's mumbo-jumbo (Jason's words, not mine) into Eclipse talk. The m2eclipse+configuration framework has integration for WTP, JDT, AJDT and they're working on one for Flex. Below is a screenshot of how m2eclipse helps developers stay away from using command-line Maven.

Now Jason is showing a demo of m2eclipse and creating a new Maven project from existing archetypes. It looks like m2eclipse uses "Nexus Indexer" as its Catalog. Presumably this is a Sonatype-hosted service. The Nexus Indexer contains an of Maven Central and is very fast. It's dynamically updated as new things are deployed to Maven Central.

If you use m2eclipse and open a pom.xml, you'll get a visual view rather than an XML view. This UI has tabs for Overview, Dependencies, Repositories, Build, Plugins, Reporting, Profiles, Team, a Dependency Hierarchy and Dependency Graph. You can easily add new dependencies and it finds things quickly because it's using the Nexus index. In addition to visually adding dependencies, you can modify the raw XML and get things like groupId and version code-completion.

Once you have your dependencies listed in a "Maven Dependencies" container to you can "Materialize Project" to create a project from the binary dependency. You'll get the source as a new project in your workspace as well as having your binary dependency turned into a source dependency.

You can easily create a run configuration that runs certain goals, allows you to activate profiles and uses an embedded version of Maven or an external installation. I asked Jason if the Dependency Hierarchy had a right-click -> exclude feature and he said it doesn't exist yet, but it will in the release after next. For now, the pom editor is just eye candy and doesn't have actions.

For Maven Plugins, m2eclipse has workspace resolution so you can develop a plugin and use it in a project at the same time w/o having to install the plugin over and over.

Sonatype has created a Project Materializer Plugin that allows a team lead to create a project for developers. It allows you to create a welcome page that has links, cheat sheets, News and Updates and Tasks for the developer. It also materializes Eclipse projects in the background. Cheat Sheets are a series of tasks that can be run to show developers how to do things.

Another big feature in m2eclipse is nested project support. It only works in Eclipse 3.4 though.

Nexus
Nexus is a repository manager that allows you to keep the cruft from the outside world out of your system. It's primarily for Repository and Configuration Management. It has fine-grained security for authentication and authorization. One nice feature of its security system is you can prevent certain users from seeing source JARs. It also has virtual repositories (a savior for OSGi lovers). UI is written in Ext JS and acts as a simple REST client for Nexus. It has a full REST API using RESTlet.

A repository manager allows you to protect yourself from the Open Source Ghetto. The OS Maven Ghetto has bad POMs, repositories in POMs, mixed snapshot and release dependencies and screwed up metadata. Not only does it offer protection, but it allows you to aggregate repositories and publish your internal artifacts to it. It also allows you to schedule tasks that clean out snapshots so your repositories don't grow out of control.

Typically people deal with OSGi runtimes manually. OSGi can dynamically update dependencies that you drop into your bundle repository. However, many folks maintain their OSGi runtime and bundle repository locally. Some people are trying to get an OSGi runtime to resolve against a P2 repository. P2 is what Eclipse uses for their repository management. Nexus has the ability to lock down the versions that are available to an OSGi runtime. Furthermore, you can use Nexus to manage the versions that get deployed to all your servers. This makes it a lot easier for QA and Production to manage versions of your artifacts. OSGi is great for modularity and solving classpath issues, but it does have issues with versions and how its ranges work.

You can see Nexus in action at http://repository.sonatype.org. It can be configured entirely through the UI, an XML file or through the REST API. RSS feeds exist for configuration and repository updates.

Nexus is free and open source with a GPL license. The next version (1.2) will contain a Plugin API to allow extensions. All of Sonatype's enhancements for its commercial version will be written as plugins. A matrix of what's available in the open source version vs. commercial version should be published sometime next week.

Hudson
Jason believes that Hudson is the future of continuous integration, on-demand results and release management. They're writing all their extension points in Hudson as Maven plugins and Plexus components (with the work they've done, using Spring components should also be possible). Other enhancements they've made to Hudson:

• Integration of JSecurity
• Implementing a similar REST layer as Nexus and creating a UI using Ext JS
• Automatic installation of external Maven installations
• Drools Workflow Integration

They've also enhanced Hudson so it can easily test/publish Maven projects without using the free-form project template. Hudson works well for doing Eclipse headless builds for Eclipse plugins. If you need to test against multiple databases, multiple OS's, it does support a grid-based system that's easy to setup. Hudson does have web services integration that allows you to kick off builds from within Eclipse. Sonatype uses Hudson to run all their nightly builds of Maven.

Maven - the best is yet to come
The three big things coming in the next version of Maven are:

• Refactored Project Builder: includes a spec for building a pom, domain-specific parsers (attribute-based XML, Groovy and Ruby) and mixins.
• Mercury: a new repository and transport layer. Developed by the Jetty people and is super fast (async client with connection pooling and parallelization). Has atomic downloads and deployments (with Nexus), full PGP support and a WebDAV client built-in.
• Maven Embedder: re-written to actually work.

Overall, a good talk with lots of demos. I'm definitely looking forward to Maven improvements in the future.

Maven Plugin for Running Integration Tests against Multiple Containers

Don Brown has created a pretty cool Maven plugin that allows you to run integration tests on multiple containers in one go. I learned about it on the Struts 2 Dev List:

I've started adding functional tests to Struts 2 by adding a few to the REST showcase application, running against Tomcat 5.x, Jetty 6.x, JBoss 4.2.x, and Resin 3.x. The magic happens through a new Maven 2 plugin I developed called maven-itblast-plugin, which enables multiple integration test runs against multiple containers in one go. For more info, see http://github.com/mrdon/maven-itblast-plugin/wikis/home.

You might notice that this plugin is hosted on GitHub. If you want to learn how to use GitHub with Maven, you might want to see Don's entry on Maven-enabled project hosting with GitHub. Thanks Don - good stuff.

Update: Don has posted more information about this plugin on his blog.

Issues with AntRun Plugin and Maven

I started seeing the following error today when using Maven and the AntRun Plugin.

[INFO] [antrun:run {execution: default}]
[INFO] Executing tasks
[INFO] ------------------------------------------------------------------------
[ERROR] BUILD ERROR
[INFO] ------------------------------------------------------------------------
[INFO] Error executing ant tasks
	
Embedded error: java.lang.IllegalAccessError: tried to access method 
org.apache.tools.ant.launch.Locator.decodeUri(Ljava/lang/String;)Ljava/lang/String; 
from class org.apache.tools.ant.AntClassLoader

Searching the internet provided no results, so I was pretty stumped - especially since this error didn't happen on my MacBook Pro. It happened on AppFuse's Bamboo server (Linux), but not locally. Luckily, I was able to reproduce it on my Windows box and discovered the solution: upgrade to a newer version of Maven. I was using 2.0.6/2.0.7 and upgrading to 2.0.9 fixed the problem.

BTW, when is the Ant project going to release a new version of Ant? The current 1.7.0 version doesn't support spaces in path names, which seems like a pretty big issue to me (especially for Windows users).

Running Spring MVC Web Applications in OSGi

For the past couple of weeks, I've been developing a web application that deploys into an OSGi container (Equinox) and uses Spring DM's Spring MVC support. The first thing I discovered was that Spring MVC's annotations weren't supported in the M1 release. This was apparently caused by a bug in Spring 2.5.3 and not Spring DM. Since Spring DM 1.1.0 M2 was released with Spring 2.5.4 today, I believe this is fixed now.

The story below is about my experience getting a Spring MVC application up and running in Equinox 3.2.2, Jetty 6.1.9 and Spring DM 1.1.0 M2 SNAPSHOT (from last week). If you want to read more about why Spring MVC + OSGi is cool, see Costin Leau's Web Applications and OSGi article.

To get a simple "Hello World" Spring MVC application working in OSGi is pretty easy. The hard part is setting up a container with all the Spring and Jetty bundles installed and started. I imagine SSAP might solve this. Luckily for me, this was done by another member of my team.

After you've done this, it's simply a matter of creating a MANIFEST.MF for your WAR that contains the proper information for OSGi to recognize. Below is the one that I used when I first tried to get my application working.

Manifest-Version: 1
Bundle-ManifestVersion: 2
Spring-DM-Version: 1.1.0-m2-SNAPSHOT
Spring-Version: 2.5.2
Bundle-Name: Simple OSGi War
Bundle-SymbolicName: myapp
Bundle-Classpath: .,WEB-INF/classes,WEB-INF/lib/freemarker-2.3.12.jar,
 WEB-INF/lib/sitemesh-2.3.jar,WEB-INF/lib/urlrewritefilter-3.0.4.jar,
 WEB-INF/lib/spring-beans-2.5.2.jar,WEB-INF/lib/spring-context-2.5.2.jar,
 WEB-INF/lib/spring-context-support-2.5.2.jar,WEB-INF/lib/spring-core-2.5.2.jar,
 WEB-INF/lib/spring-web-2.5.2.jar,WEB-INF/lib/spring-webmvc-2.5.2.jar 
Import-Package: javax.servlet,javax.servlet.http,javax.servlet.resources,javax.swing.tree,
 javax.naming,org.w3c.dom,org.apache.commons.logging,javax.xml.parsers;resolution:=optional,
 org.xml.sax;resolution:=optional,org.xml.sax.helpers;resolution:=optional

Ideally, you could generate this MANIFEST.MF using the maven-bundle-plugin. However, it doesn't support WARs in its 1.4.0 release.

You can see this is an application that uses Spring MVC, FreeMarker, SiteMesh and the URLRewriteFilter. You should be able to download it, unzip it, run "mvn package" and install it into Equinox using "install file://<path to war>".

That's all fine and dandy, but doesn't give you any benefits of OSGi. This setup works great until you try to import OSGi services using a context file with an <osgi:reference> element. After adding such a reference, it's likely you'll get the following error:

SEVERE: Context initialization failed
org.springframework.beans.factory.parsing.BeanDefinitionParsingException:
Configuration problem: Unable to locate Spring NamespaceHandler for
XML schema namespace [http://www.springframework.org/schema/osgi]

To fix this, add the following to your web.xml (if you're using ContextLoaderListener, as an <init-parameter> on DispatcherServlet if you're not):

  <context-param>
    <param-name>contextClass</param-name>
    <param-value>org.springframework.osgi.web.context.support.OsgiBundleXmlWebApplicationContext</param-value>
  </context-param>

After doing this, you might get the following error on startup:

SEVERE: Context initialization failed
org.springframework.context.ApplicationContextException: Custom
context class [org.springframework.osgi.web.context.support.OsgiBundleXmlWebApplicationContext]
is not of type [org.springframework.web.context.ConfigurableWebApplicationContext] 

To fix this, I change from referencing the Spring JARs in WEB-INF/lib to importing the packages for Spring (which were already installed in my Equinox container).

Bundle-Classpath: .,WEB-INF/classes,WEB-INF/lib/freemarker-2.3.12.jar,
 WEB-INF/lib/sitemesh-2.3.jar,WEB-INF/lib/urlrewritefilter-3.0.4.jar
Import-Package:
javax.servlet,javax.servlet.http,javax.servlet.resources,javax.swing.tree,
 javax.naming,org.w3c.dom,org.apache.commons.logging,javax.xml.parsers;resolution:=optional,
 org.xml.sax;resolution:=optional,org.xml.sax.helpers;resolution:=optional,
 org.springframework.osgi.web.context.support,
 org.springframework.context.support,
 org.springframework.web.context,
 org.springframework.web.context.support,
 org.springframework.web.servlet,
 org.springframework.web.servlet.mvc,
 org.springframework.web.servlet.mvc.support,
 org.springframework.web.servlet.view,
 org.springframework.ui,
 org.springframework.web.servlet.view.freemarker 

After rebuilding my WAR and reloading the bundle in Equinox, I was confronted with the following error message:

SEVERE: Context initialization failed
org.springframework.beans.factory.BeanCreationException: Error
creating bean with name 'freemarkerConfig' defined in ServletContext
resource [/WEB-INF/myapp-servlet.xml]: Instantiation of bean failed;
nested exception is java.lang.NoClassDefFoundError:
freemarker/cache/TemplateLoader
        at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.instantiateBean(AbstractAutowireCapableBeanFactory.java:851) 

As far as I can tell, this is because the version of Spring MVC installed in Equinox cannot resolve the FreeMarker JAR in my WEB-INF/lib directory.

To prove I wasn't going insane, I commented out my "freemarkerConfig" and "viewResolver" beans in myapp-servlet.xml and changed to a regular ol' InternalResourceViewResolver:

<bean id="viewResolver" class="org.springframework.web.servlet.view.InternalResourceViewResolver">
    <property name="prefix" value="/"/>
    <property name="suffix" value=".jsp"/>
</bean>

This worked and I was able to successfully see "Hello World" from a JSP in my browser. FreeMarker/SiteMesh worked too, but FreeMarker didn't work as a View for Spring MVC.

To attempt to solve this, I create a bundle for FreeMarker using "java -jar bnd-0.0.249.jar wrap freemarker-2.3.12.jar" and installed it in Equinox. I then change my MANIFEST.MF to use FreeMarker imports instead of referencing the JAR in WEB-INF/lib.

Bundle-Classpath:
.,WEB-INF/classes,WEB-INF/lib/sitemesh-2.3.jar,WEB-INF/lib/urlrewritefilter-3.0.4.jar
Import-Package:
javax.servlet,javax.servlet.http,javax.servlet.resources,javax.swing.tree,
 javax.naming,org.w3c.dom,org.apache.commons.logging,javax.xml.parsers;resolution:=optional,
 org.xml.sax;resolution:=optional,org.xml.sax.helpers;resolution:=optional,
 org.springframework.osgi.web.context.support,
 org.springframework.context.support,
 org.springframework.web.context,
 org.springframework.web.context.support,
 org.springframework.web.servlet,
 org.springframework.web.servlet.mvc,
 org.springframework.web.servlet.mvc.support,
 org.springframework.web.servlet.view,
 org.springframework.ui,
 org.springframework.web.servlet.view.freemarker,
 freemarker.cache,freemarker.core,freemarker.template,freemarker.ext.servlet 

Unfortunately, this still doesn't work and I still haven't been able to get FreeMarker to work with Spring MVC in OSGi. The crazy thing is I actually solved this at one point a week ago. Shortly after, I rebuilt Equinox from scratch and I'm been banging my head against the wall over this issue ever since. Last week, I entered an issue in Spring's JIRA, but thought I'd fixed it a few hours later.

I've uploaded the final project that's not working to the following URL:

http://static.raibledesigns.com/downloads/myapp-osgi.zip

If you'd like to see this project work with Spring MVC + JSP, simply modify myapp-servlet.xml to remove the FreeMarker references and use the InternalResourceViewResolver instead.

I hope Spring DM + Spring MVC supports more than just JSP as a view technology. I hope I can't get FreeMarker working because of some oversight on my part. If you have a Spring DM + Spring MVC application working with Velocity or FreeMarker, I'd love to hear about it.

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.

• Indexing Maven repositories - for offline browsing of repositories.
• Making a good use of Maven metadata - materializing projects from dependencies.
  

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.

Maven now supports attributes in pom.xml?!

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

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

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

<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:

<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>
...

<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?

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?

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]

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.

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>