Using Multiple Versions of the MobileFirst CLI Simultaneously
One of the things to be aware of when working with MobileFirst platform is that you can often have installed multiple versions of tools simultaneously, with a little care. This is something as IBM consultants we frequently need to do, as we work with different customers, but might also be of value to you, our customers, as you test out upgrades and other changes to your MobileFirst applications.
In this article, we're going to take a look at using multiple copies of the MobileFirst CLI (Command Line Interface) at the same time. The CLI is a powerful tool, and many of our customers are now using it in preference to the Eclipse platform. As consultants, we ourselves use it on a day-to-day basis. We'll focus on the Mac platform, although the principles apply to all operating systems.
Firstly, it's very easy to install the CLI into different locations, for different versions - but this won't happen by default. Normally you download the CLI from here, following the instructions to get to the Command Line Interface download package. Note that even though IBM doesn't normally encourage downloading older versions, should you need to, you can get some older versions from here - and of course you may already have a download package stashed away locally from a previous version.
Once you have your MobileFirst CLI installation package, you install it as normal (unzip the .zip file, and run the installer relevant to your platform), expect that you need to take care to change the installation directory during install. I follow a convention like this:
This means that the CLI will be installed into
/Applications/IBM/MobileFirst-CLI-7.0, and makes it very clear which each installation lies. (Note: because of a limitation in Worklight 6.2 and previous, the installer forces you to use
Worklight-CLI as the last portion of the pathname for those versions. I recommend choosing something like
/Applications/IBM/Worklight-CLI-6.2/Worklight-CLI in this case).
Note that once you have finished, the CLI installer (on Unix-like platforms, like Mac) will automatically add an entry into your
/etc/zprofile shell files that look like these:
Of course, if you install multiple versions of the MFP CLI, you will end up with multiple versions of these entries. In this case you may want to reorder them according to your preference so that your preferred version is used by default when you enter the
mobilefirst commands. (Of course, you can always enter the full path, e.g.
/Applications/IBM/MobileFirst-CLI-6.3/mfp to access a specific version directly).
Once you have your multiple versions installed, you should be aware of how they work together. Your MobileFirst projects, of course, are your own business; you can structure them on disk and in your source control system however you prefer. However, MobileFirst also needs somewhere to track the Development Server infrastructure it uses when you run commands such as
mfp deploy, etc. Typically, this sits in
~/.ibm/mobilefirst/x.y.z, where x.y.z is the version number of MobileFirst CLI you are using. (Note: in versions of the MobileFirst platform prior to 6.3, MobileFirst was called Worklight, and this directory structure is called
In general, your MobileFirst servers need not conflict. However, I highly recommend that you keep only one running at a time. You can only have one MobileFirst server per version of the MFP CLI installed, and by default they will attempt to use the same HTTP port numbers. Therefore, doing an
mfp stop on one server before attempting to run
mfp start on another will keep your job much simpler.
If everything gets too confusing, or something gets messed up, you can always delete state by removing the
~/.worklight/x.y.z directories, which will kill your servers completely (and you'll need to recreate them). But that's definitely a last resort.
I hope you find these tips helpful - write great apps!
Inclusive terminology note: The Mobile First Platform team is making changes to support the IBM® initiative to replace racially biased and other discriminatory language in our code and content with more inclusive language. While IBM values the use of inclusive language, terms that are outside of IBM's direct influence are sometimes required for the sake of maintaining user understanding. As other industry leaders join IBM in embracing the use of inclusive language, IBM will continue to update the documentation to reflect those changes.