Origins…

maven-cloudiq-plugin currently started off as a simple way to integrate the creation of CloudIQ artifacts (fabric and far files) while building a Maven project on the Mac OS. As you may know, you create CloudIQ artifacts using fabric_pkg tool.

But, currently, there is no fabric_pkg for the Mac OS X. Therefore to create a fabric or far file you end up having to do the following:

1. SCP all your files – fabric/far resources, primary artifact (jar, war, etc.), dependent libraries, scripts, etc. – to a remote host that has Appistry CloudIQ installed
2. SSH to the above remote host and run fabric_pkg to create the fabric or far artifact
3. Deploy the fabric / far artifact to the cloud

Too time-consuming in my opinion! And you end up repeating these steps over and over again. DRY principle, anyone?

Heck if you are developing (on Windows or Linux) a Java application, installation package or service that get packaged as a Fabric or Far file and are using Maven as a build tool, to create the actual fabric or far file, you have to manually run fabric_pkg. Still a pain.

Since I use Maven a heck lot, I had to eliminate some of the repeated tasks. And thus the maven-cloudiq-plugin came forth. The primary objective of which was to integrate and make easy the building of CloudIQ artifacts while building a Maven project.

Looking forward…

Enough with the origins. What can we expect moving forward?

Although I won’t go into every single enhancement or new feature here (I haven’t thought about everything; that’s where you could contribute), I will list out some of the pressing issues that would greatly improve the usability of the plugin.

Some enhancements and features:

1. Auto-increment the fabric or far version in the application descriptors by looking up the latest version running in the cloud. Also, allow for manual override by user. Currently, the user has to update the application descriptors manually.
2. Auto-creation of Fabric and Far application descriptors. Currently, the user has to create these application descriptors by hand.
3. Auto-discover the appropriate CloudIQ artifact (.fabric or .far) that needs to be generated. Currently, the default is fabric. This is configurable though via the appExtension parameter.
4. Ability to deploy CloudIQ artifacts (and files) to clouds.
5. Ability to specify the list of dependent jars required at fabric package time. Currently, the entire kitchen sink of Maven dependencies get downloaded even though only a handful of jars gets included in the fabric file
6. Capture remote fabric_pkg output & error stream and log it out to the standard output during the Maven build.

So, above are some features/enhancements that need working on along with unit tests.

Interested enough to contribute?

If you are interested in contributing to the enhancements, features, and bug-fixes and making the maven-cloudiq-plugin robust and easy to use, feel free to clone the repository, send/attach code snippets, add additional enhancement/feature requests, etc.

Google Code and Mercurial
While I did not spend a ton of time evaluating a public project hosting provider, some of key things I was looking for in a project hosting provider was:

• Must provide DVCS (distributed version control system)
• Must provider some type of issue tracking system

Although GitHub and BitBucket seemed to fit the bill, I decided to go with Google code since it offers Mercurial DVCS (and Subversion as well). Mercurial (hg), IMHO, is faster and easier to learn than other DVCS. Again, this is purely my opinion.

Eclipse IDE has a nice plugin for hg. And NetBeans comes with support for hg out of the box.

How to contribute
If you are reading this post, I would encourage you to contribute to the development of maven-cloudiq-plugin. You can do so easily by cloning the project, fixing bugs, developing new features, requesting new features, and so on.

What is the purpose of the Appistry CloudIQ Maven plugin? See here

The three features I really like about PuTTY-CM are:

• Ability to re-size and arrange windows (SSH sessions to multiple Linux machines) within the parent window
• Ability to execute a command across multiple active SSH sessions at the same time

The ability to execute the same command on multiple SSH sessions is HUGE for me given that I am generally working with either VMs or multiple physical machines at any given point of time.

I have googled quite a bit to find an equivalent of PuTTY-CM for the Mac. And the closest I have come is iTerm.
I say closest, since iTerm does not have the feature of re-sizing/re-arranging the SSH sessions (tabs) within a parent window.

But hey, the ability to “Send Input to all tabs” (Shift + Command + I) within a window is still HUGE and an excellent feature over the Terminal app that comes bundled with the Mac OS X.

I generally categorize my projects into multiple Eclipse workspaces and at times like having them open at the same time. In Windows/Linux OSes, this is a no-brainer – just click on the shortcut and this will start up a new process. But in Mac OS X, clicking on the Eclipse launcher in the taskbar just brought the existing Eclipse process into the foreground.

Finally I found out that I could accomplish what I wanted with the open command. Add it to a script as shown below and bingo, starting up multiple Eclipse workspaces is a piece of cake.

#!/bin/bash

ECLIPSE_HOME=~/tools/editors/eclipse35-JEE-x86_64/eclipse
open -n $ECLIPSE_HOME/Eclipse.App