Okay so we know that inheritance is bad and that inter-package inheiritance is even worse but just because you know that doesn’t mean that you don’t have to deal with it. The latest Gordian Knot at work is project dependencies within WSAD projects but the root cause is, I suspect, a dangerous infatuation with inheritance as a solution for everything.

The problem I had was trying to share functionality between an EJB client and server layer. Logical solution: introduce a new project that contains all the common functionality and simply make the existing projects use that as a dependancy. However the pervading view of “nothing new” that afflicts my workplace got to me and I decided instead to try and just massage the functionality of the existing projects.

When I merged my work in ClearCase the .classpath file blew up and wouldn’t parse. Since these files are “secret” Eclipse project files it can be bugger to get them back into a workable state. In this case I could get the file to be to be valid XML but it still wouldn’t work (probably because it couldn’t reconcile to something else in the Workspace like the Project Set or the project file). In these cases I’ve always just created an entirely new classpath file for the project. In fact having your project files blow up can be a good chance to see what exactly your code does and doesn’t need.

Having the classpath blow up can be a huge warning sign as well. The project I work on has about 5000 to 20000 warnings depending on the level of concern you want to set. Usually I like to work with very strict warning levels but in this case it did me no favours because after I reconstructed my class path I completely failed to notice the significance of the circular build warnings that appeared.

Visually this is a major flaw in WSAD, a circular build dependency is actually a bigger issue than an unused method parameter but visually they are identical in the WSAD Task pane. I am also a little surprised that it is only a warning.

WSAD can resolve the dependency by stacking build requests; building one project until it gets a dependency then building the dependent project until it gets another dependency then asking the original project to be built and then unwinding the stack of building requests. It adds a little extra time to the full build time but compared to the huge amount of time required by a full enterprise build it is very hard to notice any change and in fact it seamlessly resolves most project linking issues allowing you to be very generous in creating project dependencies and using larger workspaces.

My problem is that there is a headless build script that is used during the construction of an application from a given ClearCase baseline and this headless build (despite being nominally an identical process to the WSAD GUI build) cannot seem to stack build requests in the same way and thus the circular dependency kills the build script. The pain of WSAD headless builds is a topic for another post but the script’s failure introduces yet another dependency as the build script is now defining the structure of the projects in the application. If the build script cannot work with the changes you make in WSAD then the code overall is deemed to fail.

This is more process than technology but it still adds to the general sensation of being more of a magician spinning plates when working with large, legacy EJB apps in WSAD than any kind of professional programmer.