I love JIRA, I really do, so long as I never have to do any administration to it.
I’ve got a JIRA instance set up as a household to-do system. Today, I tried installing JIRA 4.1 as a test instance, upgrading from version 4.0. It turns out I won’t be making that upgrade for real any time soon, as 4.1 breaks many of the plugins I need for my JIRA workflow. If I upgraded, I’d cripple my setup beyond usability.
Unfortunately, Atlassian has chosen to leave many obvious and necessary workflow actions out of JIRA, instead relying upon third-party plugins to provide them. This wouldn’t be a problem if Atlassian didn’t change their plugin API more often than Tiger Woods picks up new sexual partners.
Okay, so I figured I’d at least upgrade to version 4.0.2; I’ve been putting that off for too long. It’s anything but an easy process, especially when you’re running the EAR/WAR version instead of their “standalone” that comes with its own Tomcat instance. They don’t have a standalone build for FreeBSD, so I don’t really have a choice.
Although the process is really convoluted and something only a Java wonk could love, it wouldn’t be so bad except that JIRA’s plugin system is so horrible. JIRA plugins are generally Java .jar files. There are two kinds of JIRA plugin now, Version 1 and Version 2. It’s not obvious from looking at a plugin what kind it is. You have to either go to Atlassian’s plugin repository and find it there, and the page will tell you what version the plugin is… or you have to extract the plugin and go digging in XML files trying to find a setting that will exist only if it’s version 2.
Depending on whether it’s version 1 or version 2, the plugin has to go in one of two widely different directories. If it’s version 1, it goes in a directory that will need to be wiped out when you upgrade JIRA.
What’s so bad about that? It’s also the directory that houses dozens of JIRA’s own .jar files, and there’s no way to tell which ones are part of JIRA and which ones are plugins. In fact, there’s no way to tell what plugins you’ve installed short of doing a file-by-file comparison with a clean JIRA installation of the same version.
Better document that JIRA installation really well as you do it…!
It gets better! Some Version 2 plugins won’t work from their new, plugins-only directory anyway! You won’t find this out until they fail to work, and then you dig through the log file—which Atlassian so thoughtfully creates in whatever working directory you happened to be when you started Tomcat—and see a message that you have to copy the file to the old directory!
Of course, if you merely copy the file, as directed by the error message, you’ll get another warning that there are two copies installed so you can’t use either…
Did I mention that every time you add or remove a plugin, you have to restart Tomcat? If you don’t have some really rockin’ hardware running your JIRA instance, that’ll bring you a minute or two of downtime. It’s annoying with three users in one household; it’d be a bloody outrage if I were supporting a large company with this.
What’s particularly galling is that Atlassian’s other major product, Confluence, does plugins so well. You can search the Confluence plugin repository from within your Confluence instance’s administration screens. You can see which plugins you’ve installed, and if they’re out of date Confluence will tell you so and offer you a link to download and install the latest version. There’s even a web-upload link to install .jar files from outside of the Atlassian repository. Atlassian knows how to do this right. They just haven’t bothered with JIRA.
So, I do my upgrade. This entails backing up the current JIRA instance to XML, creating a new database for the new JIRA, installing the new JIRA instance, copying over a number of settings files, tweaking my Tomcat settings, copying over plugins I’d backed up previously, restarting a few times to get the database loaded and the plugins in place, etc. etc. …
…and then the bloody thing doesn’t show any of my workflow actions, because I’m one plugin short. It doesn’t even clearly tell me “hey, you have workflow actions that don’t seem to be defined” anyplace useful. It just doesn’t show me any workflow actions. When I go into my workflow editor, the only clue is that some workflow actions look like
Type: class Class: com.googlecode.jsu.workflow.function.UpdateIssueCustomFieldPostFunction Arguments: field.value = Yes field.name = customfield_10040
instead of
The Needs Parts of the issue will be set to Yes.
Notice how there’s also no hint whatsoever as to which plugin you previously had that’s now AWOL; you’re left to figure that out on your own.
After finally figuring out which plugin was missing—the one that implements the ability to change the value of a field other than the default ones provided with a generic JIRA install—installing it, starting, finding no improvement, finding the log error saying it’s in the wrong place, moving it, restarting… I finally have my workflow actions back, and I’m an hour behind on my other tasks for the day.
Then there’s the security patch. The boys at Atlassian had a rather embarrassing security breach recently. It highlighted a number of XSS attacks against JIRA. None of the code currently available for download includes the fixes, so you have to apply the patch. For EAR/WAR installs like mine, this involves:
-
- Extracting the patch files on top of the source for JIRA
- Rebuilding the WAR file
- Stopping Tomcat
- Copying the WAR file into place
- Backing up your existing Version 1 plugins, which Atlassian doesn’t bother to mention in the instructions, so hopefully you understand this consequence of what they do tell you
- Deleting the Tomcat work directory, because otherwise Tomcat may cache the old .jar files
- Creating a new Tomcat work directory by hand, which Atlassian doesn’t mention; if you don’t, Tomcat will appear to start but won’t actually run anything…
- Deleting the old jira directory, because otherwise Tomcat may not unpack the new .jar files, which isn’t mentioned in the patch directions but is mentioned in a troubleshooting section under new installs for when you upgrade and find upon restart that you haven’t, in fact, successfully upgraded
- Starting Tomcat
- Waiting for Tomcat to start JIRA
- Stopping Tomcat
- Reinstalling the Version 1 plugins
- Starting Tomcat
That’s one of the more convoluted “security patch” procedures I’ve ever had to deal with in over 15 years as a professional UNIX systems administrator.
If you’re thinking of buying JIRA for your business: If you can’t afford to hire a Java guru to be your full-time JIRA guy, don’t bother. You will need someone who understands Java and databases and Apache Tomcat and your choice of operating system, and they’ll have their hands full.
13 Responses to No, really, JIRA pisses me off.
Leave a Reply
You must be logged in to post a comment.
Hi Rob,
Disclaimer: I work at Atlassian on JIRA.
Firstly – glad to hear you still love loving JIRA despite the challenges you have faced.
We understand your frustration with the upgrade process on JIRA, and agree that it can be much much better. Thanks for writing down your woes here so we can focus on where to improve. Some of the difficulties you raise here are very specific to the EAR/WAR installation, which is certainly much more complex than the standalone installation. This is why we strongly recommend all our customers use the standalone installation. As far as we are aware, the standalone version of JIRA should run fine on FreeBSD – is there something specifc that isn’t working for you?
> Atlassian has chosen to leave many obvious and necessary workflow actions out of JIRA
We have chosen our workflow to be generic and accomodating as we could – unfortunately, that does mean it doesn’t work for everyone. However, we are curious about which particular actions you had in mind?
> it wouldn’t be so bad except that JIRA’s plugin system is so horrible.
With regards to the plugin system. Again, we understand that the process isn’t optimal right now. However, we are already hard at work on improving the plugin administration side of things. We are currently making the JIRA and Confluence experience the same, and at some stage, connecting our plugin system to our plugin repository at plugins.atlassian.com.
> That’s one of the more convoluted “security patch” procedures I’ve ever had to deal with in over 15 years as a professional UNIX systems administrator.
Again, we understand the process of patching the EAR/WAR installation can be easier. However, there are a few things we can recommend to reduce the complexity:
* Instead of deleting the entire Tomcat work directory (step 6), you can instead just delete the contents. This will remove the need for step 7. Our documentation isn’t clear on this so apologies, we’ll make sure to clean it up in future patch instructions.
* To our understanding, it should not be necessary to delete the jira directory that Tomcat unpacks to (step 8), as Tomcat should have the ability to update that directory itself.
* For re-installing plugins 1 plugins, it would be much easier to install the plugins into the edit-webapp directory (during step 2) instead, removing the need to go through steps 10-13.
Regards,
Edwin
Atlassian
Edwin,
Thanks for the quick reply.
Well, the JIRA Download Center only lists Windows, Mac OS X, and Linux as platforms. While it’s possible to run Linux binaries on FreeBSD, it’s not necessarily fast. In the absence of any information to the contrary, I went with running a FreeBSD-native Tomcat and Java stack. While Atlassian refers to “Linux/UNIX” a lot, when it comes time to download the software all you see is “Linux.”
You say that here, but your installation documentation tells a different story. I found this out after my first attempt at starting JIRA after upgrading from 4.0 to 4.0.2 came up with the 4.0 version number still in the footer. The linked troubleshooting instructions say:
After getting burned on that once, I wasn’t going to get burned again after installing the patch. My step 8 will remain in my local procedures until proven unnecessary…
That’s at odds with the instructions for installing JIRA plugins found on Atlassian’s web site. The instructions there are pretty clear that Version 1 and Version 2 plugins go into different directories. In fact, in a big yellow warning box, one reads:
Although the instructions don’t explicitly say that you can’t put Version 1 plugins safely into the Version 2 directory, they very strongly imply that doing so would be a Bad Idea.
If that’s not true, then someone needs to go find out what the technical writers have been doing with their time…
Hi Rob,
Thanks for the detailed response.
> That’s at odds with the instructions for installing JIRA plugins found on Atlassian’s web site. The instructions there are pretty clear that Version 1 and Version 2 plugins go into different directories
I think we have mis-communicated here. What I meant was that version 1 plugins could be directly installed directly into the war, not that plugins 1 and plugins 2 can be in the same directory. Happy to take this offline if you would like, just drop me a mail.
Regards,
Edwin
You wrote: “If you’re thinking of buying JIRA for your business: If you can’t afford to hire a Java guru to be your full-time JIRA guy, don’t bother. You will need someone who understands Java and databases and Apache Tomcat and your choice of operating system, and they’ll have their hands full.”
That’s me! I run a consulting business around software development environments (based in San Jose, CA) and about 70% of my work is with JIRA. Most of that is customization, but I do my share of upgrades and configurations too. Everything you’ve described above is true and has bitten me at one time or another 🙁
The upgrade pain around plugins should be reduced by the Universal Plugin Manager that is available for early access, but I still plan on doing a series of test upgrades to find all these kinds of problems before I even consider doing a production upgrade.
I agree that most of those custom functions and fields you listed should be rolled into a production instance of JIRA. It’s been long enough.
IMO, you don’t need some full-time to manage JIRA, but if you have more than a dozen developers you should have someone full-time to manage all the development environment tools they use. It’s the same reason that IT departments exist – to let the coders code more of the time.
It is said that misery loves company, I can soooo relate to your pain. I’m an engineer with a large defense contractor and in addition to my usual duties I am pulled off occasionally for months at a time to “fix” this or that feature in JIRA, or to add additional functionality via plugins or source mods, etc. Be glad you only have to administer for your home, your comment about needing a full-time Java developer are spot on. Especially, like Matt said, since most companies using it need so much more than what the stock JIRA delivers.
I have to say though that over the past five years Atlassian has moved JIRA out of a not-overexaggerated-hellish-mess of software into something that can begrudgingly be called workable from a developer standpoint. It still seems like they’re moving at a snail’s pace but it _is_ getting better. We just upgraded from 4.1.1 to 4.3.4 and I was able to do the migration of plugins, source mods, and the JIRA system in about a week. Much better than the six to eight weeks it took a couple of years ago.
I have used JIRA for a long time and have also encountered some of the issues that you have mentioned. However I have also found it to be one of the most flexible systems around for this type of function and allows itself to be highly customized. If JIRA is not meeting your needs what alternatives would you propose?
Hey – on the topic of
“Did I mention that every time you add or remove a plugin, you have to restart Tomcat? If you don’t have some really rockin’ hardware running your JIRA instance, that’ll bring you a minute or two of downtime. It’s annoying with three users in one household; it’d be a bloody outrage if I were supporting a large company with this.”
If you download the atlassian plugin SDK and deploy your own builds of JIRA (I don’t think it requires the JIRA source), you can use FastDEV mode to not have to restart tomcat if changes in plugins occur. I may be wrong.
But consider FastDEV mode which doesn’t require you to take JIRA offline – which I thought was cool.
This is the problem that we don’t have a lot of alternatives. We have Jira enterprise and I was assigned to create a complicated workflow. Well, to do most of the complicated “stuff” I need special plugins that are not fully supported or expensive from Jira. The latest release of Jira does not work with custom email template that were working on previous version, pulldown, etc… did they forget to test?! For me it is a expensive system that does NOT deliver what we pay for. If I have the power I will change to another system. This was supposed to be an easy work; I have assigned one resource 100% just to work on configuration and another for administration… I’m sorry but I don’t think it is such a great system right now.
Cassan, I definitely agree that it seems like backwards compatibility is not on Atlassian’s radar. It seems like large swaths of functionality needed by real-world JIRA users is implemented by plugins, and Atlassian doesn’t really seem to care if they break those plugins or not. Nor do they seem to be good at figuring out which highly popular plugins are features that really ought to be integrated into JIRA and fully supported.
Look at the past fiasco with the Calendar plugin for Confluence, which broke for a good while before being replaced by a paid plugin. In the meantime, we decided not to bother with Confluence for our team calendar any more—too unreliable—and migrated to SharePoint for calendaring. As a plus, we gained Outlook integration from that move.
And, ironically, just after posting that I check my email and find a message from Atlassian announcing Confluence 5, now with yet another user interface and more API changes that I’m willing to bet will break all our plugins again. I wonder if enough of them will be made compatible with Confluence 5 for us to consider upgrading before Confluence 6 comes out…
m’kay, sounds like I’m going standalone today…
I’m wondering why all of you are still using this terrible product when there are so many good alternatives on the market. TestTrack from Seapine comes to mind, we’ve been using it for quite some time and the workflow is so much better, not to mention it is fully integrated for requirements and test management, strong traceability and no plug-ins required.
SLA’s won’t save in our JIRA service desk build 6252
Have spent 40 hours on this so far, which could have been spent on other issues. – the issue is mentioned in a variety of JSD- issues being tracked at Atlassian.
Strongly recommending switch to Spiceworks to management and team.
—————————————————–
We cannot upgrade – next version breaks our plugins (sorry, add ins now) and no budget allocation to buy next version of all add ins until next budget year.
Recommendation, avoid until Atlassian is past growth stage of business and moves into stable plateau.