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

The JHipster Mini-Book The JHipster Mini-Book is a guide to getting started with hip technologies today: AngularJS, Bootstrap, and Spring Boot. All of these frameworks are wrapped up in an easy-to-use project called JHipster.

This book shows you how to build an app with JHipster, and guides you through the plethora of tools, techniques and options you can use. Furthermore, it explains the UI and API building blocks so you understand the underpinnings of your great application.

For book updates, follow @jhipster-book on Twitter.

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.

AppFuse, Reduced

In 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 by looking at its mailing list traffic.

AppFuse Mailing List Traffic, December 2014

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.

AppFuse Maven Central Stats, November 2014

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:

  1. 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.
  2. Defined plugins, their versions and configurations in <pluginManagement>.
  3. Defined dependencies, their versions and exclusions in <dependencyManagement>.
  4. 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:

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.

Posted in Java at Dec 16 2014, 06:03:31 AM MST 6 Comments
Comments:

I really like simplification. I want to focus on using the pieces as I work on an open source project based on AppFuse. E.g. I am content with hibernate-data but still have questions about complexity and how I can solve that and give that knowledge back to AppFuse. I was thinking about choice of dispatch servlet-architecture/UI layer and how most applications tend to evolve into the monstrosities of bad design. I used to think that stored procedures and javascript were unnecessary. My company now uses stored procedures heavily and I don't see how that could ever change. The model is so complex and it's a product of years of not taking the time to refactor. And, javascript is used now for one product (jquery) where another not so much (hand-written javascript and prototype). Both products are used by 1000 financial clients and over 3 million individual users. The performance is about the same. I manage, develop, and team lead for new development and accept interruptions to deal with production environment. I have always wanted to shut down the servers for different companies, install an AppFuse archetype, move in the model objects and fix the ones that are missing or covered with bad code and/or stored procedures. If I hear "we can't use Maven because our dependencies are too complicated .." I'm going to scream. Looks to me like your direction Matt is perfect.

I like your plan and I want to help you solve the complexity issue when the pages want way more than several services. I'm going to do my project light-weight, informal, maybe not so agile, maybe no scrum, but focus on clear, understandable requirements and watch the application evolve and hope to learn something that AppFuse can use to take it to a new level. You know that moment when the project manager, says "our best client wants this .." and your stomach drops. You get this ill feeling and you say, "what a dumbass." on the inside. Your going to do it but you wish that AppFuse had some Maven magic command string that let you either just do it with ease or convince the "No-Change-Executive-In-Charge" that this is not that difficult. After all the stored procedures are put to bed in the repo, the data reporting developers come to feed on them for the client reports. Now you revise the Java and the stored procedures and cringe everytime you commit for fear that you just broke something.

Do you think that all new feature development should take things back to the database schema? There's no better Java web quick-start application than AppFuse. None. But I want to find out how to fix the application monstrosity or create one that doesn't become a monstrosity. Call me Dr. Frankenstein.

Posted by David L. Whitehurst on December 17, 2014 at 08:27 AM MST #

Hi Matt,

I know that any feedback is always helpful so I just want to add a little comment on your text:
"I think the biggest value that AppFuse provides now is a learning tool for those who work on it."

Yes indeed. I'm using AppFuse as a tool, starting point when I'm teaching a students on University of Novi Sad, Serbia (Faculty of Technical Sciences). It's a subject "Architecture of Information Systems" where I'm teaching assistant.
AppFuse helps me a lot when I want to present
- all layers 'in action' in application with modern (Java web oriented) architecture
- using of various open source frameworks
- generating a code for application just based on domain model (POJO classes)
- generating a nice looking application with all CRUD operations
- lots of other advantages...

So, just continue in the same direction. There are people that really appreciate you work and effort :)


Nenad

Posted by Nenad on December 17, 2014 at 08:27 AM MST #

I also use AppFuse along with Java 7, Maven 3 and MySQL 5 for a few of my projects. Its a pretty common setup and very easy to work with.

Posted by alex on December 30, 2014 at 12:15 PM MST #

AppFuse paid my bills for 7 years.

Now, is for me a good start point for learn new technologies. Continues with the excellent work.

Regards from Perú

Joe

Posted by José Díaz on December 30, 2014 at 12:15 PM MST #

Hi Matt

Been following you for a while now and using AppFuse as a means of learning and development. Recently switched to the 3.5.0 release, and from my point of view, this does ease maintenance, however, I prefer not having appfuse as the parent POM.

I feel using the full pom approach allows me more visibility and aids the learning process.

Any way to get the full POM back?

Posted by Ettiene on March 08, 2015 at 07:34 PM MDT #

Ettiene - the fastest way to get the full pom back would be to run "mvn help:effective-pom" and replace your pom with the XML output. It'll include all the dependencies managed by Spring IO Platform in its <dependencyManagement> section, but you can delete many of them.

Another option is to copy the relevant sections from appfuse-web and the root pom.

Posted by Matt Raible on March 08, 2015 at 07:40 PM MDT #

Post a Comment:
  • HTML Syntax: Allowed