Fork me on GitHub

n. Slang a rough lawless young Kuali developer.
[perhaps variant of Houlihan, Irish surname]
kualiganism n

Blog of an rSmart Java Developer. Full of code examples, solutions, best practices, et al.

Sunday, March 18, 2012

Kuali Coeus Overlay Reference Implementation

Overview

Just 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 kc.technical.collab@kuali.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

Modules

I 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


Core is the main project that contains java source and datadictionary/Spring resources



Web


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.



wsdl2java

Before, 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 pluginManagement

I moved things in here to minimize configuration in the overlaying project. It worked out great.

Tomcat Hackery

One 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 Hackery

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

Screencasts

Check it out:




If you have anything to add, please do. If there are any problems with the project or the code, please give me a ring.

Also, stay tuned for updates to the reference implementations for both KC and KFS. I will soon be adding an embedded Directory Service via Spring that will allow you to play around with the LDAP module in the reference implementations.

Wednesday, March 7, 2012

KFS Overlay Reference Implementation Screencasts

Overview

I created a screencast to illustrate the simplicity of downloading the kfs overlay reference implementation project from github, building the packages, installing them, and running them. The goal here is to get people downloading, using, and modifying quickly. Feel free to checkout the distribution and fork it, change things, and communicate back with me on your findings.

The Screencast








What Doesn't Work

Now that you've seen it function in a single specific use case, let me throw out which use cases do not work.

tomcat plugin

Because of some problems with filtering web resources, the web.xml does not filter correctly with the tomcat plugin. I am going to fix this and publish another screencast beholding its awesomeness.

jetty plugin

This has the same issue as the tomcat plugin.

Liquibase

Working on this. I will add liquibase to the reference implementation with a screencast. This way you can try out the reference implementation with real liquibase change management enabled and configured.

Turn key automation

This doesn't work yet, but I hope to make the reference implementation even simpler. At this time, you are forced to setup your own database and make sure it is suitable for KFS before using the reference implementation. The goal is that in the future, everything is plug-n-play.

Friday, March 2, 2012

UPDATE: Building Applications with the Kuali POMs

Overview


I have updated the kfs-public POM by overriding the kuali <distributionManagement /> section. Since you cannot actually remove anything out of it, I have overridden the repositories so they will point to maven central instead of nexus.


Upon installation, it looks something like this:


This eliminates the problem with the AWS security. Also, kudos to Travis Schneeberger for the suggestion of pointing to Maven Central. My inclination was actually to point to a local repository. After deliberating on it, I realized that people would probably not be too happy about that.