My childhood home really had it all.
Nice deck overlooking Callahan State Park, bicycle-friendy cul-de-sac, open living room with French windows, eat-in kitchen, and suburban zip code.
For years, it even had a hugeass Oak tree that seasonally fired acorns at your skull if you dared retrieve the mail.
So my parents never moved, and that’s why I’m friends with the same fuckers I knew back in preschool. I guess the house just worked for my folks.
And it must have worked for my neighborhood’s developers too, because don’t you know – they put three-hundred just like it next door.
[STAMP] 7 Rolling Drive [STAMP] 9 Rolling Drive [STAMP] 11 Rolling Drive …
Clearly, the economies of scale provided by a reproducible build plan were obvious to those guys.
My least favorite responsibility as Application Developer is the composition and maintenance of build files. Every once in awhile I’ll read a book that cites different roles within an organization – DBA, Backend Programmer, Frontend Programmer, GUI Designer, Assembler, Deployer, SysAdmin – and wonder why I’m doing all of them for one paycheck. I always wished there was some sucker down the hall with a business card that read “Assembly Engineer” to whom I could shove off all copy/compile/JAR tasks before going about my day.
Guess I’ve never been lucky enough to have that resource.
Here’s the problem: As simple as JBossAS is to get set up, once you start developing your application it’s likely that your server configuration will begin to sway from the default. It’s no longer an “unpack and run” situation, and this introduces a dangerous element; the environment used for local development might look very different from that used in primetime. Unless these changes are kept in check, it’s really easy to introduce bugs. Your application is not what you craft alone, but the sum total of all code churning at runtime. Everything needs to play nicely.
Easily fixed; with the introduction of an automated process, we can install and configure our server at the click of a button. This will keep our various environments in sync, with explicit differences we knowingly introduce.
I used to accomplish these goals using a series of Ant scripts, but anyone with experience in this arena knows how hellish making extensible Ant files can be. And forget cross-project portability. So this time around I’ll piggyback on Maven’s conventions.
Though close, CodeHaus’s jboss-maven-plugin didn’t quite hit the nail on the head for me. Architecturally, I needed some backing common libraries (unbound to the Maven Plugin API) such that I could mashup many of the components together for the new JBoss EJB3 Mavenized TestSuite. Not to mention that the SVN links are either outdated or the project is gonzo (Anyone? Bueller?), and I needed to add features.
Therefore, now under construction is the JBossAS Control Maven Plugin. This Blog entry is a Request for Comments.
Current Roadmap of Supported Goals Targeted for 1.0.0.GA:
Check for an installation at $JBOSS_HOME, and if not there, download and unpack a fresh version. May run in forced mode to always wipe the existing installation. Before I release this feature I’ll have to check with the appropriate channels about the legality of grabbing binaries from SourceForge, if there are some consent agreements or other useless red tape that have to be addressed.
From a specified base, create a new configuration. Customize by adding/overwriting/deleting as appropriate. This starts us off from a well-known default, applies the delta that makes our custom configuration, and exits. An added benefit is that we know our custom changes implicitly. KISS.
Grab the specified deployable unit(s) and deploy ‘em.
Control-Z the deployment of specified artifacts.
Start a JBossAS configuration with appropriate JVM/Server arguments.
What goes up, must come down.
Anything else I should be including? Or specific implementation requests for these features?
In the short term, I’ll update this entry with Anonymous SVN Access and links to other instructions when they become available.
I think that should do it for this project’s scope. Also in the works right now is a functional sample project illustrating the proper configuration of these goals within the Maven Lifecycle. With one command you can get a fresh copy of the server, configure it, start it up, deploy your application, run integration tests, and bring the whole thing down before generating reports.
Good for continuous build. Good for ensuring your local development environments are sync’d up with the stuff you’re putting in Stage/Production.
[STAMP] My Application 1 [STAMP] My Application 2 [STAMP] MyApplication 3 …
Well-planned integration testing addresses the differences in your server environments.
[STAMP] My Application 4 …
Reproducible build plan at every level is an absolute necessity.
Until you come home drunk one night, and can’t find your house because they all look the damn same.
Continuous Integration, Martin Fowler, 2006