OverviewJust as I did with KFS Overlay Reference Implementation Screencasts, I created some screencasts and a GitHub project for a reference implementation for Kuali Coeus. The motivation for this mostly came from a thread on firstname.lastname@example.org about Maven Overlay Docs.
Overlays by themselves are pretty straightforward. It's no big deal. You have a war, you want to build your project on top of a war. You overlay it.
Where things get tricky is development and choosing between jetty or tomcat. Before I explain what the issue is here, let me first point out that the concept of an overlay is for packaging and distribution. It is not a pattern intended for development. When you want to create an overlay war and deploy it to an application server, there is never any problem.
The problem occurs in development. Kuali supports both jetty and tomcat for development. Tomcat is even recommended for implementations. However, the maven tomcat and jetty plugins behave in very different ways from each other. While jetty seems to work out of the box each time, tomcat requires some gentle massaging. I decided that the Kuali Coeus maven project could be improved on to help in this area. I created a GitHub project for Kuali Coeus version 3.2. In this project I made some changes:
Changes I Made
ModulesI broke everything into maven modules. I created a core and web module. This is consistent with the way Kuali now patterns its maven projects.
Core is the main project that contains java source and datadictionary/Spring resources
This is what will be the final product of the application. It depends upon core. All of the profiles are to do with the war packaging, so those were moved into the web module.
wsdl2javaBefore, there was a flag here to not inherit wsdl2java. The reason for this is the expectance of an overlay. Should anyone overlay this project and make it the parent, there would be problems with inheriting the cxf-codegen-plugin. I was able to remove that because this plugin is now configured in core which is not inherited.
dependencyManagement and pluginManagementI moved things in here to minimize configuration in the overlaying project. It worked out great.
Tomcat HackeryOne of the problems I found with tomcat is that despite efforts made to support overlays like MTOMCAT-100, classpath resources were not being loaded by the WebappClassLoader. Just jars and classes. Things like Spring configuration, tag files, context configurations, and tlds were left at the door. I needed to find a way to handle this during development. What I came up with is to create a profile to handle this.
Basically, I am exploding the overlay into the current webapp to get tomcat to see the files. I make sure it doesn't overwrite any files incase I make changes. It also does not run more than once. A marker is created by the maven dependency plugin. This way it only attempts to unpack once ever.
Datadictionary HackeryI used the solution for tomcat again with the datadictionary. Tomcat and Jetty both were having trouble reading datadictionary and spring files from the classpath jars like rice and the overlay. To get around this, I did this:
which unpacks the datadictionary. Again, it will only do this once, so I don't continuously incur the overhead. It also is only necessary for my overlaying datadictionary jar.