Openmake has made available a new build method for CapeClear ESB WSAR builds.   The  CapeClear Web Services builds can now be automated using this reusable build method.

Perl offers various ways to share/reuse code.  When enhancing perl code/modules used in multiple applications and/or parallel releases, it is important to ensure that we get an early warning if the change made is not backward compatible and if there is a potential for the existing applications to break.  With “use” we would know if a reference is made to an unavailable module at compile time itself.  However, there are cases, when we need to be backward compatible and allow the existing applications that share code to function seamlessly.  Using “require” instead of “use” has come in handy to ensure that the existing applications continue to work and at the same time allow the new releases to use the new functionality.  This is because “require” is more dynamic and loads the modules at run time when needed and not at compile time unlike “use”. 

Perhaps you’ve heard of “glue” scripting, which is scripting designed to pull together various tools and processes into an integrated process automation.For example, suppose you have both ClearQuest from IBM and CA Harvest. Neither IBM nor CA have a real stake in integrating with the competitor’s tool, but you do. So what do you do? You create some nifty Perl scripts (because there are no other real scripting languages) to associate Harvest package promotion with ClearQuest record changes.

Well, we in OM Services have become sort of a people form of the same thing. We’ve had multiple engagements with the same companies, providing a consistent level of expertise and proprietary knowledge of each company’s software processes and automation technology.

Sometimes we even smooth out transitions from staff turnover and that’s where I think we act as “glue” in time. OK, so I have a physics background and can’t distinguish between time and space, but providing connectivity between two points is sort of what we do.

The goals of an SCM team charged with build management is to NOT have proprietary knowledge outside the team, but well, that can be expensive and sometimes impossible even when the funds are there. So, while we strive to meet the needs of our customers through services, we think the tool should provide that bridge, keeping the proprietary knowledge in house, and we in services are constantly feeding back our input into product development to achieve that goal.

We’ve heard from a number of companies that they are having problems with their WebSphere Eclipse headless builds and they are looking to us for a solution.

A headless build is an Eclipse function (and therefore an IBM WSAD/RAD IDE function) that allows you to execute Eclipse and some of it’s plug-ins at the command line. The GUI does not launch, but the main machinery does, and it makes use of the workspace metadata.

In theory this allows you to do the same build at the command line that was done in the GUI. It’s a nice theory that we subscribe to ourselves.

In practice, these companies do not feel they are successful for a number of reasons:

1. If it works it is slow. A slow build is almost as bad as a broken build.
2. Unexplained crashes in the middle of the build due to workspace corruption.
3. Crashes may leave the .lock file in the .metadata folder of the workspace. This prevents Eclipse from executing in the same location until it is cleaned up.
4. It’s a black-box build with a large number of operation swept

Meister takes a different approach and records the files and project types and then applies a traditional build with a mixture of Ant tasks and command line calls. This eliminates the need to even install RAD 7 on the build server, but you still need the runtime libraries.

I’ve worked with the IBM WebSphere EJBDeploy plug-ins and integrated Meister to actually call an Eclipse headless build via the WSAD/RAD ejbdeploy.bat file. As a rule, we always stick with the vendor-recommended approach, so we don’t have a choice. However, we don’t do the compiling and archive this way - just the EJBDeploy step.

By compiling and archiving the Java parts in a traditional way, we at least minimize the risk of a broken headless build and maximize the speed. And, yes the ejbdeploy step is usually the longest step in the build. The fact that IBM supplies the ejbdeploy.bat file at all, which mimics a command-line compiler, means we’re not the only ones taking this approach.

I’d like to see more users on Git and to do that it needs to have a robust Windows client like TortoiseCVS and TortoiseSVN. It turns out there is such a client, called Cheetah.

There is a UNIX-like runtime environment on Windows called MinGW and a minimum install set called msys. When you download Git to a Windows machine it includes msys and all the awesome *NIX commands and filters I can’t live without.The corresponding project page for Git running with msys is here: Git on Google Code.

In order to promote Git, I joined the msysGit Google group and offered my help to Johannes Schindelin. It looks like they might need some help managing requirements and bug tracking.

Also, weird karma - my first job after college was a summer job at theMax Planck Institutes and Johannes is there now.

On a related note, people are still having trouble with make. Here’s a note about case preservation problems when doing cross-platform builds. Well, the problem is implied, given that this is a post describing a solution.

Given that this functionality has been missing from make for decades of doing cross-platform builds, I have to question if this is really necessary. Is the root cause of the problem something else?

I’m going to contribute my CA Harvest knowledge to the Perl VCI module. Max Alexander-Kanat, who runs that uses the bazaar code control tool for that. So far I haven’t used that one, but I’m all up for it.

I was wondering how many code control tools I’ve used. Here is a list and a tally:

SCCS, RCS, PVCS/Version Manager, Endevor Workstation (RIP), Endevor for UNIX (RIP), Endevor mainframe, CVS, Subversion, CA Harvest, MKS Source Integrity, Perforce, Git, Microsoft Visual Source Safe, ClearCase, StarTeam, Serena ChangeMan for Distributed Platforms (RIP), Serena Dimensions. Total 17 - only 17?

There are a couple more tools that I saw or downloaded, but did not actually use like Microsoft’s Team Foundation Server, IBM’s CMVC (nearly RIP) and Aldon’s Lifecycle Manager for AS/400.

I’ll take that last one about ensuring a drive is mapped and make a Mojo activity template out of it so you only have to enter the drive letter and the share name. Here’s another one…

I have a workflow that can only run on a specific machine because it assumes certain software is installed (Git in this case). To fail a workflow that is not running on the correct machine, run this shell command at the beginning of the workflow:

if not “%COMPUTERNAME%”==”ASLAN” exit 1

I’ll make an activity template out of that one also, so then you only have to enter the computername. Note that this is case sensitive!

It’s true we can make one out of Perl that is platform independent.

In order to verify that a drive is mapped on Windows, and if not, map it, and then have the command complete with a successful return code, use this command:

dir O: > nul || net use O: \\computer\myshare

It should only return a fail code when it is unable to map a drive. I’m using this in one of my Mojo workflow activities…

I’ll be trying out BlogDesk - looks good. I have been using Microsoft Word 2007, which was OK, but it was difficult to assign categories. I was actually uploading the blog, then logging in to WordPress and applying the categories afterwards.I’ll also be blogging more frequently, so I have to make the process as smooth as possible. If you have another fave, let me know. You can send me a Tweet, also: at seanblanton.

I led a session at BarCamp Milwaukee this weekend on the Git code control tool. I prepared for a look-at-my-laptop presentation for the 4 people who signed up by Friday. At the appointed time about 30 people showed up to a room with no projector (about 1/4^th of the conference attendees). Now, that’s the kind of thing to keep you on your toes!

Several of the developers knew the tool better than I did and so I became the discussion leader. We talked about the basics, distributed development, branching, the Eclipse plug-in and suitability for the enterprise (the verdict was “yes, it is”).

In general, a lot believe Git is superior to both CVS, Subversion and even ClearCase. Git has advantages in checkout speed, branch support and is better for supporting builds. It is fundamentally different in that it supports a distributed development model. But, it is similar to CVS and Subversion in that it is basically a command-line tool with little GUI support (compared with tools like Perforce, StarTeam and AccuRev) and lack of enterprise integration and reporting capabilities that high-end SCM tools have like Team Foundation Server, Serena Dimensions, IBM Jazz and CA Harvest.

There was also forklift driving and a build-and-take-home your own robot sessions there in addition to functional programming and PostgreSQL.