AppFuse, Reduced
by
Join the DZone community and get the full member experience.
Join For Free(n November, I had some time off between clients. To occupy my time, I exercised my body and brain a bit. I spent a couple hours a day exercising and a few hours a day working on AppFuse. AppFuse isn't used to start projects nearly as much as it once was. This makes sense since there's been a ton of innovation on the JVM and there's lots of get-started-quickly frameworks now. Among my favorites are Spring Boot, JHipster, Grails and Play.
You can see that AppFuse's community activity has decreased quite a bit over the years if you look its mailing list traffic.
Even though there's not a lot of users talking on the mailing list, it still seems to get quite a few downloads from Maven Central.
I think the biggest value that AppFuse provides now is a learning tool for those who work on it. Also, it's a good place to show other developers how they can evolve with open source frameworks (e.g. Spring, Hibernate, JSF, Tapestry, Struts) over several years. Showing how we migrated to Spring MVC Test, for example, might be useful. The upcoming move to Spring Data instead of our Generic DAO solution might be interesting as well.
Regardless of whether AppFuse is used a lot or not, it should be easy to maintain. Over the several weeks, I made some opinionated changes and achieved some pretty good progress on simplifying things and making the project easier to maintain. The previous structure has a lot of duplicate versions, properties and plugin configurations between different projects. I was able to leverage Maven's inheritance model to make a number of improvements:
- Changed AppFuse's parent to be based on the Spring IO Platform. This project is a dependency manager that defines version numbers for open source projects that work well with Spring.
- Defined plugins, their versions and configurations in
<pluginManagement>. - Defined dependencies, their versions and exclusions in
<dependencyManagement>. - Simplified archetypes so new projects have minimal dependencies. For example, here's a basic project's
pom.xml:
<?xml version="1.0" encoding="UTF-8"?>
<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.company</groupId>
<artifactId>springmvc-project</artifactId>
<packaging>war</packaging>
<version>1.0-SNAPSHOT</version>
<name>AppFuse Spring MVC Application</name>
<parent>
<groupId>org.appfuse</groupId>
<artifactId>appfuse-web</artifactId>
<version>3.5.0-SNAPSHOT</version>
</parent>
<build>
<plugins>
<plugin>
<groupId>de.juplo</groupId>
<artifactId>hibernate4-maven-plugin</artifactId>
</plugin>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>dbunit-maven-plugin</artifactId>
</plugin>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>build-helper-maven-plugin</artifactId>
</plugin>
</plugins>
</build>
<dependencies>
<dependency>
<groupId>org.appfuse</groupId>
<artifactId>appfuse-${web.framework}</artifactId>
<version>${appfuse.version}</version>
<type>pom</type>
</dependency>
</dependencies>
<properties>
<amp.genericCore>true</amp.genericCore>
<amp.fullSource>false</amp.fullSource>
<dao.framework>hibernate</dao.framework>
<db.name>mydatabase</db.name>
<web.framework>spring</web.framework>
<!-- Framework/Plugin versions -->
<appfuse.version>3.5.0-SNAPSHOT</appfuse.version>
<java.version>1.7</java.version>
</properties>
<profiles>
<profile>
<id>itest</id>
<build>
<plugins>
<plugin>
<groupId>org.codehaus.cargo</groupId>
<artifactId>cargo-maven2-plugin</artifactId>
</plugin>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>webtest-maven-plugin</artifactId>
</plugin>
</plugins>
</build>
</profile>
</profiles>
<reporting>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>webtest-maven-plugin</artifactId>
</plugin>
</plugins>
</reporting>
</project>The pull request for these changes says it all:
- AppFuse +4,822 -14,369
- AppFuse Light +776 -4,687
That's right, I was able to eliminate a good chunk of code without affecting any of AppFuse's functionality1. I think we can all agree that less code == easier maintenance. This theme will continue as we work on future releases.
Other improvements include migrating all tests to use JUnit4, integrating Spring MVC Test, and configuring the surefire plugin to run tests in parallel. I also The build-helper-maven-plugin is now used to find open ports for Cargo to run and a lot of testing was done to ensure you can build/test multiple AppFuse-derived projects at the same time. Finally, I migrated to the hibernate4-maven-plugin and upgraded to Tapestry 5.4.
In the next version of AppFuse, I plan to remove as much XML as possible - moving all of the configuration to Spring's JavaConfig. We'll also be moving to Java 8 as a minimum. I'm even considering getting rid of all the pom.xml files in favor of another build language that requires less code.
In other words, the upcoming 3.5 release will be the last release that supports Java 7 and uses Spring's XML for configuration. AppFuse 4.0 will strive for #NoXML. The project's roadmap has more details on additional hopes and dreams.
We'd love to hear your feedback on these change. Do you like the simplification theme? Are you OK with having AppFuse as a parent in your projects?
1. For project and code stats, see AppFuse on Open Hub.
Published at DZone with permission of Matt Raible, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.
Comments