Re: Re: three WMQ gems : Package / Deploy

Charles, unless you are going to be sshing into the machine hosting the
MQ
server and doing your work directly on it, I believe you will need to at
least install the WMQ
clienthttp://pic.dhe.ibm.com/infocenter/wmqv7/v7r1/topic/com.ibm.mq.doc/zi00110_.htmand
get them connected just to be able to use the APIs, but I might be
wrong on that one.

As for your deployment issues, have you looked at something like
Vagranthttp://www.vagrantup.com/,
boxen http://boxen.github.com/, puppet http://puppetlabs.com/, or
chefhttp://www.opscode.com/chef/.
Instead of packaging everything into a single executable installer, youd
essentially script an installation that could then set up your app on
the
clients machines. While there would be some time spent configuring your
scripts initially, what you want to do sounds like exactly the sort of
situation these tools were built for: repeatable, predictable automated
deployments into multiple environments .

As you say, there is no 1-click solution. Any app of enough complexity
and
with requirements that differ enough from usual conventions that tools
like
rawr or warbler arent working for you off the shelf, is going to need
significant customization and configuration in its build process. Tools
that offer enough flexibility to give said app the room to make those
configurations are going to either be too low level (rake, for
instance),
or too complex (maven) to truly be single-click. Youll either take
low-level tools and get the customized build process you need by
composing
and scripting them to do what you want, or take a complex, high-level
tool and configure your build with some sort of config files, or command
line options, or whatever.

All that said, Im certain theres plenty of room for improvements in our
build tools, additional automation and better abstractions.

BTW, Ive mentioned it a couple times before, but the JavaFX packaging
tools (which can be used on any Java/Jruby app that needs native
installers, not just JavaFX/JRubyFX apps) will package the JRE along
with
the app. It becomes completely self-contained .deb or .rpm installers
for
linux, .dmg for osx, and exe or msi for windows.

On Fri, Oct 11, 2013 at 6:32 PM, Charles M. [email protected]
wrote:

Eric:

Eric:

thanks for your input , I appreciate it.

I should have made myself more clear. What I mean by a one click
installer sounds like could be the packager functionality in JavaFX and
I think I must have missed your post on that , I thought that would be
specific for javafx/jrubyfx apps, I will certainly check it out.

I’m familiar with Vagrant and know of Chef and Puppet. Yes, Vagrant
would be used for setting up system dependencies on target machines.

What I mean is that I need something that will grab my code, grab the
JRE, all the gems I depend on, all the external jars I depend on, will
make sure that “our code” is compiled to .class files, gems and jars can
be left in their native state, and will provide an option of generating
a single executable depending on OS context , or at least an executable
Jar (compiled “our code”) but bring the JRE along to be installed along
with the executable jar. This beast will be embodied in a generated
installer preferably a single executable itself e.g.used Nullsoft on
Windows, or whatever on Mac and perhaps a generated script on Linux.

As far as making sure system dependencies such WMQ client libs, xml
processing libs , db client libs, etc that’s where the admins at the
customer side kick in given our specs , I’ve used Vagrant to setup my
internal testing vmware instances, I have suggested Vagrant to them. Its
all running on Vmware “hyper” virrtualization system, not sure if Vmware
has Vagrant-ish mechanisms.

Finally I thought that the WMQ client Jars are self sufficient and that
they themselves don’t rely on C libs but that was just an assumption.
Yes, I will be testing MQ from within our network or beg for a port to
be opened on a isolated test box so that I can also test from home.

thanks

Charles