Question

I’m using gradle to manage a multi-project J2EE build – the end-goal is to produces a series of server package/artifacts that can be deployed to a target server, unzipped, and run.

In other words, each artifact contains everything it needs to run – minus the JDK.

The project structure looks somewhat like so:

Root project 'proto' - This is the master-build project
+--- Project ':applications' - Default build settings for applications
|    +--- Project ':applications:foo' - Foo API
|    +--- Project ':applications:bar' - Bar API
|    \--- Project ':applications:baz' - Baz API
+--- Project ':common' - Common code shared by multiple projects
|    \--- Project ':common:subcomponents' - Settings shared by subcomponents
|         +--- Project ':common:subcomponents:configuration' - Configuration
|         \--- Project ':common:subcomponents:initializer' - Initializers
+--- Project ':servers' - Default tasks for building server artifacts
|    +--- Project ':servers:foobar' - Assembles and runs the foobar server
|    +--- Project ':servers:foobaz' - Assembles and runs the foobaz server
|    \--- Project ':servers:barbaz' - Assembles and runs the barbaz server
\--- Project ':webapps' - These are the defaults for webapps
     +--- Project ':webapps:foo' - The webapp for foo
     +--- Project ':webapps:bar' - The webapp for bar
     \--- Project ':webapps:baz' - The webapp for baz

Building common, apps and webapps as dependencies of each other is pretty straight-forward but building the servers projects have proven to be somewhat of a challenge.

My current approach is to use a bare-bones server in the “servers” folder and copy it’s contents over to the taget server being built, then copy war files to it and zip it all up… but my root/servers/build.gradle is starting to look a mess.

So the question is — would writing an ‘ear’ style plug-in help simplify my server builds?

Also of note, I’m currently using resin-pro-3.0.25 but planning on switching to another server container soon (next couple of months), which brings me to a tangent question – are other folks using similar approaches when building server artifacts for tomcat / jetty?

Your thoughts are greatly appreciated!

Answer 1

I think that separating bundling logic in a separate script is always worthwhile, because it also simplifies using it in another project. Also note that you don’t necessarily need to write a plugin to accomplish this task — you can start with script in buildSrc directory in the main project.

I guess that subprojects of :servers store some configuration to be injected into distributable, so your structure makes sense to me. The script would then define a new task that would retrieve all the files by convention (common directory structure for :servers project, taking WAR from :webapps subproject of the same name as the one we’re being executed on…).

As for your last question, I think that this depends on target OS — e.g. if it’s Debian maybe producing a package that contains only the application WAR and configuration and depends on the container package (either from official repo, or built by you) would be more natural for me.