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.

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.

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

Thanks for the quick reply.

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?

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.”

However, we are curious about which particular actions you had in mind?

• Most of what’s implemented by JIRA Misc Workflow Extensions, particularly:
  • Condition on the previous status of an issue
  • Validator: Multi-select field has not more than one value during a transition
  • Validator: Field value must be changed during the transition
  • Validator: Comment must be provided during the transition
  • Action: Assign the issue to a role member
• Virtually all of the JIRA Suite Utilities, particularly:
  • Condition: User Is In Any Groups (user must be in one of a list of groups in order to execute the transition)
  • Condition: Value Field (user can only execute transition if a given field has a specified value)
  • Condition: User Is In Custom Field (custom field must be set to the current user in order to execute the transition)
  • Validator: Fields Required (list of fields that must have some value set)
  • Validator: Date Compare (compare two date fields)
  • Validator: Window Dates (compare two date fields using a sliding window)
  • Action: Copy Value From Other Field
  • Action: Update Issue Custom Field, which I am highlighting because it seems like such a basic function for a program like JIRA; Atlassian provides a way to set default fields during transitions, but user defined fields depend on a plugin!
  • Action: Clear Field Value (yes, out of the box, JIRA can’t clear the contents of a field on a transition.)
• Some of the JIRA Toolkit Plugin, which was apparently created by Atlassian when a stock-out-of-the-box JIRA instance couldn’t even meet Atlassian’s needs:
  • The “Message Custom Field” field types, which let you put explanatory text into your screens
• The vanEfferenOnline.nl Workflow Plugin, which provides the “Assign to Group Member” function
• The Email Issue Plugin, which lets you e-mail a JIRA issue to an arbitrary recipient manually

* 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.

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:

If you have made changes to $JIRA_INSTALL/edit-webapp/WEB-INF/classes/entityengine.xml ( step 2 ) and re-run the build script ( step 3 ), but your changes are not being picked up, delete the Tomcat webapps/jira directory, then restart JIRA. It would seem that in some circumstances Tomcat does not correctly re-expand the web application.

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…

* 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.

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:

If you copy the JIRA jar file of a ‘Version 1′ plugin into the installation directory for ‘Version 2′ plugins (or vice versa), JIRA provides a warning, indicating that the plugin has been installed into the wrong directory.

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…

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