In the blog Albees Online, Albin Joseph expresses his frustration that he’s stuck using the buggiest IDE in the World (WebSphere Integration Developer). I’m going to include my thoughts below:

Most of the times the server wouldn’t change the status to started even if the server is actually started

Agreed. There’s something wrong with the communication between WID and WPS over the RMI protocol where the tool either ignores or doesn’t receive the “Started” message. The stupid part is that this problem has existed in the tool since v6.0 with no real resolution in sight. The workaround? Open your WID Server configuration (double click the server in the Servers view), and change the RMI setting to SOAP or SOAP to RMI. Save the editor and your server will now be started.

publishing would not work, not able to add a project to the server,

I’ve also had this problem where either the publishing would fail randomly or a builder would generate an error. Theres two workarounds that I use. The first would be to re-build the generated ear files but deleting the EJB/WEB/APP projects in the resources view and then initiating a clean build. If that didn’t work, I would remove the ear from the server and restart the server. This usually ‘fixes’ the problem. In the extreme cases, I would export my workspace into a Project Interchange file, create a new workspace and re-import.

the changes made in a project will not be reflected in the server and so on.

Again, this is a legitimate problem between the interactions of WID and WPS. Process server seems to hate iterative development. It caches and optimizes based on every app-install on the assumption that the server will be untouched for long periods of time. This directly conflicts with the usage pattern of most developers. In the more recent ifixes of the tool, I’ve used the task view warning to re-deploy the ear as needed and have greatly reduced the instances of changes not being reflected.

If all these things worked, then we will get a series of exception with some stupid ids. If we search the error code in IBM infocenter we will get an explanation that is no way matches with the problem we are facing.

Agreed, problem determination in this stack is very difficult. You either know the solution because you’ve seen the exception hundreds of times, or you spin your wheels debugging ‘ghosts’. I think this is a reflection of the architecture of products being built on products being built on products. It’s a great way to design a system, leveraging domain experts to solve common problems. I think the issue comes when the developer who uses a dependency doesn’t take ownership of the problem, but rather points a finger at the lower level and shrugs. As it stands now, by being a developer on WID, you also have to be an expert on Rational Application Developer, WebSphere Process Server, WebSphere Application Server, Eclipse, WSDL, EMF etc.

If someone from IBM reads this post, please please test your products before you release it to the end user and please give some proper explanations and how to solve these issues in your infocenter.

They do get tested, the problem is that WebSphere Integration Developer is built off of so many products and includes such a wide variety of usage patterns, that it’s impossible to test them all. That has led to the documentation of ‘Best Practices’ as a guide to attempt to keep developers along the ‘most traveled and tested’ path.