Plug it in, Plug it in.

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[1] 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



  1. Have you looked at the Maven Cargo plugin? Perhaps it got some/all of the features you like?

  2. Tobias · · Reply

    How are you going to address the plethora of xml-files that one would like to tune for configuring the server?

    Are you interested in some real world requirements for adjustments that need to be made for a productive JBoss server?

  3. Tobias:

    “How are you going to address the plethora of xml-files that one would like to tune for configuring the server?”

    The eeeeasy way. By letting you copy/overwrite/delete ’em in their entirety. Not adding any intelligent management here, just a mechanism to write bytes.

    “Are you interested in some real world requirements for adjustments that need to be made for a productive JBoss server?”

    If you’ve got some I haven’t addressed, absolutely.


  4. Viggo:

    Somehow addressing Cargo never made it from my outline to this draft when I went to press. :) Whoopsie.

    Cargo is an awesome project on many levels. I dig its mission and I dig its implementation. It’s modular, can be invoked programmatically, via Ant, Maven, etc, and supports many containers.

    The reason this didn’t fit the bill for me was its support for JBossAS specifically, and I just couldn’t get the server configurations in line with my requirements for the EJB3 TestSuite setup. So I instead decided to take advantage of some code that JBoss QA had already written and write some layers on top of it. When all’s said and done, I’d like to do a gap analysis between the JBossAS Control Plugin and Cargo, and port things over or get ’em upstream / consolidate as appropriate.

    So the two do indeed have overlapping features at the moment. Going to press forward and see where the strengths of each lie.


  5. Roberto Melo Cavalcante · · Reply


    I read about your plugin and I would like to know how it would be possible to make the deployment of an exploded EAR.
    First, let me try to give an overview of my project’s reality. My project has some jar modules and 1 war module that we are packing into an exploded war. We are actually, achieving this goal through an ant script but all my modules already have their own POM.xml that are being used more like a library artifact than a way to use Maven as a tool for packing and deploy to our JBossAS.
    The projects are not connect with a parent POM of any sort.
    I would like to know if we can accomplish this goal and if possible, can you provide us the POMs’ entries for that?
    I knew about your work thanks to Edson Tirelli [] he may have sent you an e-mail with a simple JBoss deploy problem in a company Redhat is giving some trainning.
    Thanks in advance for your help

  6. Roberto:

    Though I haven’t had the time yet to address the deploy Mojo for the plugin, it’s a pretty trivial task that I’d be happy to walk you through if you’d like to contribute.

    We haven’t yet done a release of the Plugin (more pressing issues), but the ones in place work pretty reliably for development purposes.

    Feel free to email me.


  7. Roberto Melo Cavalcante · · Reply


    I read what you said about contribution and due to my really short time, I’m afraid I can contribute only writing a guide explaining how to use your plugin to make deployment, ear packing, POM inheritance and profile configuration for Maven.
    We could use a real project like one of yours. I think the article/guide could evolve to help developers to create a culture for version control and configuration management with Maven.
    I already started that guide, I have web a page with some material already posted.
    If this kind of contribution is of any interest, please let me know about any ideas you may want to see in this guide.
    BTW, I would really appreciate if you can give me any tips on how to use your plugin for deployment on JBoss. Last time I wrote you my projects were not connected, now I’m testing POM inheritance in order to pack an ear. Just after that, I’m going to need the deployment config.
    Can you tell me if there is another plugin capable of making network-through deployment, such as the JMX like yours do?
    I apologize myself for any English syntax or concordance mistakes I may have run into. English is not my first language.
    Thanks for your reply and help.
    PS: Can you send me an e-mail? I couldn’t find yours in this page.

  8. Roberto:

    Sorry for the latency; I hadn’t seen this latest post of yours.

    Yes, any and all contribution (especially documentation) is welcome and appreciated.

    The components to make the Maven “deploy” Mojo should be mostly in place; I’ll see what can be done to couple this together. From there, maybe we’ll do a Beta1 release.

    The JMX Deployment currently contains references to a filesystem URL, so it’s not quite network-enabled yet. Some enhancements on the AS side to accept a byte array and deploy that would correct this, but that’d need some more attention. On a local machine this would work as expected.

    My email is andrew dot rubinger at jboss dot org.


  9. deploy / undeploy done ;)

  10. > Current Roadmap of Supported Goals Targeted for 1.0.0.GA:

    Yes, it will be something about I have thought for couple of months ;) According me I wonder that developers use manual copying to maintain developer / production environment.

    Correct way is:

    1. Download sources from repository
    2. Set some specific variables / properties in one/few files.
    2. Run some scripts to set up developer / production environment without manual copying

    and viola ;)

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


Get every new post delivered to your Inbox.

%d bloggers like this: