It's been a challenge getting the most recent release of The Gliffy Plugin for Confluence shipped.

What follows is a long nerdy story describing one of the challenges we have faced getting Confluence 1.4.0 shipped. If you don't want to read the whole story, do please take note that it ends with this important notice: The Gliffy Plugin for Confluence 1.4.0 will require Confluence 2.6 or better.

One of the biggest problems we've encountered is related to the fact that we've tried really really hard to support as many older versions of Confluence as possible. This dedication does, on occasion, create big headaches for us. Sometimes, I've learned, we just can't have our cake and eat it too.

So what's going on?

Our story begins way back in November of 2006 when we first released the Gliffy Plugin for Confluence (GPFC for short). Be forewarned, this is going to get geeky real fast.

A brief overview about how GPFC is architected
When you save a diagram in Confluence, it is written out in an XML format. That's just great, but XML isn't exactly a human readable format. We overcome this by transcoding our Gliffy XML format to SVG, and then use the software package Batik to transcode the SVG to an image.

So what's the problem?
Well, it turns out that Confluence versions 2.2 through 2.5 all ship with Batik 1.5 pre installed. Unfortunately, Gliffy requires Batik 1.6 in order to render diagrams correctly. Probably the most elegant solution at this point is to let the Confluence Plugin Class Loader solve this by letting us bundle any number of jars with the plugin distribution. The idea is that the Plugin Class Loader should be smart enough to load classes bundled with the Plugin first (ie, Batik 1.6 which we require) before trying to load classes from anywhere else (ie Batik 1.5 that ships with Confluence 2.2). Unfortunately, back in the early days of Confluence 2.2, the plugin class loader wasn't very smart, and I'm pretty sure it couldn't even load jars bundled with plugins at that time.

Back in November 2006 when we first released the GPFC, it was critical that we supported as many older versions of Confluence as possible since we knew there would be a ton of customers using those older versions. In fact, back then we were compatible with some Confluence versions in the 1.X series. Anyway, how did we solve the problem?

The Hack
The solution ended up being pretty filthy. Basically, we changed the namespace of the version of Batik we needed from org.apache.batik to gliffyorg.apache.batik, then compiled from source. This allowed us to ship Batik 1.6 with our plugin without running into naming conflicts with the 1.5 version of Batik that is shipped with Confluence.

In retrospect, this probably wasn't the best solution, but it did solve our problem at the time. If I ran into a similar problem again, I'd probably look more seriously into writing our own class loader as a means for guaranteeing we'd get the versions of a class or library we needed.... but with Confluence this might not be a trivial task since Clustered versions of Confluence store plugins in the database. Arrrr!

So what's the problem now?
One of the big new features in the GPFC 1.4 is our new symbol libraries. The new symbol libraries are WAY better looking than the old ones, and they generally behave a lot better too. The Gliffy Plugin for Confluence 1.4 will have an awesome set of Network Diagram Symbols, Floor Plan symbols, Wireframe Symbols, and more. When were finally merged the new symbol library codebase with the GPFC, we noticed there were some issues with our re-namespaced version of Batik.... basically, the new symbol libraries didn't work with our munged version of Batik. Somehow, we introduced a bug when we re-namespaced Batik.

Now, it's important to realize that Batik is no small bit of code. Digging into why things weren't rendering correctly was going to be no small task.... and we knew that this hacky-go-lucky thing we had going on with the whole re-namspacing business was... well... unclean in the first place.

We needed a new solution
This got us starting to look at the whole problem again with fresh eyes. We tried a whole bunch of solutions that ended up being dead ends. I tried re-namspacing Batik 1.7 , hoping that the before mentioned rendering issue would just go away. This ended up having it's own set of issues, plus this was just the same unclean strategy as we had tried before.

I then spent some time looking into seeing which versions of Confluence would let us bundle Batik 1.6 un-modified. Unfortunately, with all versions of Confluence, I was unable to bundle Batik due to yet another class loader problem in Batik or Confluence....

Is this worth it?
It was about this time Friday that I started to get pretty annoyed. Here I am, trying to get the GPFC setup so that customers can take advantage of all these great new symbol libraries, but at the same time watching the clock tick by as I'm stuck trying to solve these annoying problems that seemingly have no solutions. Think about it: Our customers aren't getting access to a new version of our software simply because we're trying so hard to support old versions of Confluence.

So we started to re-think assumptions, as we often do. My chief concern all this time has been that we didn't want to upset current customers by requiring them to upgrade to a recent version of Confluence to get new features.

Well, we tried really hard to support older versions of Confluence with this release, but it's just not going to happen. Sorry. :(

The Solution
At the end of it all, we've decided that The Gliffy Plugin for Confluence 1.4.0 will require Confluence 2.6 or better. Why? Since Confluence 2.6 ships with Batik 1.6, the whole issue just goes away.

Now, back to the original concern, which is that we want to make sure our customers don't feel like they are forced to upgrade Confluence to get the most recent version of Gliffy. Well, our thinking in this area is that if a customer hasn't upgraded to Confluence 2.6 or better in the 9 months since it has been available, upgrading to the GPFC 1.4.0 probably isn't at the top of their list either. Some other plugins, such as the Calendar Plugin, require versions of Confluence as recent as 2.8 to get the latest and greatest plugin features.

OK, if you got this far, thanks for reading. Do please let us know in the comments to this post, or by contacting support directly, if requiring Confluence 2.6 for the next feature release of the Gliffy Plugin for Confluence is asking too much.... we want to hear from you!