Rediscovering Maven's assembly plugin

Our team was faced with the following (actually quite simple) task: Extract all configuration files from the WAR (or rather the jars inside the war) and deploy them separately, while at the same time allowing the lazy efficient developers to just continue using mvn tomee:run like nothing changed. The reasoning behind this separate deployment was that we want to be able to change the configuration without having to rebuild the war.

Since our project is fully Maven-based, it seemed quite obvious that the solution to this must involve the assembly plugin. Personally, I had only one experience with it from a few years back, and it sure has evolved since then. Effectively, all goals except for one (+ help) have been deprecated. WOW! Nevertheless, it's still extremely powerful. So powerful that reading the documentation can lead to quite a bit of confusion and headache.

Don't get me wrong, I haven't found anything that's really missing. It's just overwhelming, because the assembly descriptor can do so many useful things.
We came up with a solution which I have outlined in a simple demo project in my GitHub account. The basic steps were:

1. Extract the config files into their own separate maven module.
2. Add this maven module as dependency with scope test where needed (this will normally be the module they were extracted from). In the example project, this is happening in modularised-webapp-library.
3. Don't add the configuration as dependency to the war project. Instead, add it as a server library to the tomee plugin as demonstrated here.
4. Create another maven module only for the assembly which has dependencies onto the war and the configuration module.
5. In the assembly descriptor, define two separate dependency sets. The one for the configuration module unpacks the configuration module and removes the maven metadata, while the one for the war only copies the war directly.

That's really it. Took us quite some effort to find this solution, but I really like the overall simplicity.

The architect is happy, because he can edit the files as he wishes without redeployment. The developers are happy, because the tomee plugin is still running the way we're used to.

(And I'm happy, because I can show off some knowledge again. ;-) )

What is your experience with building assemblies?

License Analysis with Maven

Last week I learned about the License Maven Plugin's real value. As developers, we usually just want to do our work and therefore become upset about "unimportant" things that get in our way. One of these things that we don't like to think about are licensing terms. When we find a library, we want to use it - and not undergo a tedious governance process which includes a deep analysis of the library's license, the library's dependencies' licenses, the dependencies' dependencies' licenses etc.

For me, it's "always" been normal just to grab the dependencies that I need from "somewhat" trustworthy sources. However, when you develop commercial software, there are some legal implications. One of the main considerations is the license question. And since more and more libraries depend on other libraries themselves, you must examine the whole tree. Doing this manually can take up a lot of time.

Take for example the Smooks library I'm currently looking at. It's more than a library; Smooks defines itself rather as a framework. It is used to process different data file formats and perform transformations between them. The project has been in development for several years now and as such "naturally" picked up a lot of 3rd party dependencies over this time.

Now imagine yourself sitting there as a developer who wants to use this library (or in this case framework). So you go ahead and add it to your maven dependencies. You mention this to your colleagues/team lead/... Suddenly, somebody with authority steps in and asks: "Did you check the license terms? And what about all the dependencies we're pulling in transitively now?"

This situation is far more common than most of us will like to admit. Of course, you can now go ahead and check the specific library's license, then look at its dependencies and do the same with these - all manually. But if the dependencies have dependencies which again have dependencies and so on... - well, you get the picture. This will probably work out quite fine for a simple library with dependencies that go no deeper than two levels. Beyond that, you can decide to either keep an intern busy for a day or two - or look for a technical tool.

The technical tool I found is the above mentioned License Maven Plugin. The usage page is a bit massive, but for my relatively simple purposes, these steps were sufficient:

1. Add the plugin to the build section within the main Maven POM:
   <build>
        <plugins>
            <plugin>
                <groupId>org.codehaus.mojo</groupId>
                <artifactId>license-maven-plugin</artifactId>
                <version>1.8</version>
            </plugin>
        </plugins>
   </build>
2. Call mvn license:aggregate-add-third-party. In case of a single module project, you'd instead use the goal add-third-party.
   
3. This will produce a file called THIRD-PARTY.txt in the folder target/generated-sources/license of the project you made the call in.
   
4. This file lists all dependencies (including the transitive ones) in all child modules with their associated licenses (or Unknown license if that particular dependency contains no license information).
   

This file is what you can pass on to whoever asks you this kind of annoying question. Enjoy!