Atlassian's documentation for integrating with JIRA through their webservices - while not non-existent - may as well be. I am having to guess what values are. I can't seem to find them through the UI. I am stuck on this error atm;

com.atlassian.jira.rpc.exception.RemoteValidationException: {} : [Security Level: Security Level is required.]

We are intergrating our system with different issue management systems so that if we have errors or things expiring on the queues we can throw them into one of the issue management systems so a human can look at them and determine the root cause. It took me a morning to knock together the client and the EARs. It has taken a day and a half to try and work out how to send the information JIRA wants and I am still stuck.

I am going to have to use their support system. I am not impressed. I remember one vendor we integrated with when we asked them details on how their stuff worked, the reply was; over and over; "Look at the WSDL". If you can imagine that in a thick Portugese accent that had heavy emphasis on the 'W'. WSDLs dont self carry documentation which is a failing of the SOAP/WSDL architecture in my opinion.

Atlassian outdoes themselves in this area though. Even the arguments to the webmethods are not well named. They are in0, in1, in2 etc in a webmethod. Fair dinkum.

More Got it integrated. Next stop is Manage Engine's ticketing system.

One of the reasons we are transitioning over to maven is because Bamboo was unable to handle our ant scripts that took care of our dependency management. Our ant scripts weren't that complex, and our dependencies aren't that bad; we have very few common libraries, but it was too much for Bamboo.

Now that we have mavenized several projects we are hitting the same wall. As soon as you even abstract slightly - in our case so our version number is one place - then Bamboo is flat out not up to the task. As a continuous integration server it is little more than a toy unless you have a very simple project with no cross project dependencies or any source control repository complexity.

Have even one degree of freedom outside of a monolithic jar and single source repository and Bamboo fails to deliver. You end up making your scripts too complex and hitting Bamboo's limitations very quickly.

Mavenizing our projects is worth it. We are seeing benefits already. However, bamboo is not. Hudson is immediately superior. I will be pushing for us to use that as our main Continuous Integration Server. I have an instance of it set up on my machine. I will have to convince folks that the switch is worth it.

We recently upgraded to the new version of Bamboo from Atlassian. I think it is 3.x.something. I am not impressed. The new version hides the logs under stages so you have to click around ad-infinitum to find them. The files that it pulls down, useful for seeing what is in the target/ so you can compare what is going into the EAR, WAR and JARs is hidden as well. I end up clicking around fifty times trying to find where things are. Configuring a plan is now just as bad, some of it is in the stage, some in the plan, etc. Ugh.

What really infuriates me though is that I test all these maven plans on my machine before I run them on bamboo. Albeit, my machine is a Mac Pro and I run them from the command line, but I have profiles for localhost and all the integration environments. When it runs on Bamboo - which is on top of a Windows 7 Server - without fail, it will not work. I end up having to debug Bamboo every time. This means the maven scripts aren't portable between bash and Bamboo. This is a waste of time, it is frustrating, and also unnecessary.

I don't have a good relationship with Bamboo. About the only thing I can say is that once you debug the Bamboo environment and the maven scripts it usually settles down and is low maintenance, but until then the error messages are different, and it is difficult to debug the build scripts on Bamboo. Not fun.

Rant Continues - Our EARs have multiple sub projects to them. For instance there is the DTOs and Remote interfaces that stub the EJBs. There is the EJB project, the WS layer, and to make sure vendor WSDLs don't change on us silently we gen several JAX-WS client projects as well. Hence our parent poms have extensive profiles that are geared toward each integration environment.

Run the profiles in bash and no worries. Everything builds without issue. Do the same in Bamboo and the parent pom doesn't build, and the pom that deploys the Service Bus also fails. However, separate out the parent pom and Service Bus deployment pom into separate stages and they work without fail. It is a Bamboo thing, but it means there are now three deployment plans when it should all be under one.

You end up with a choice. Fight Bamboo for an extended period or just give in and have increasing numbers of plans that need to be managed for each other rather then one build, test, and deploy plan. Frustrating, frustrating, frustrating.