Many of the commercial enterprisey tools/components/servers available today major on WYSIWYG, point click, drag drop style development. Which is great, I’m all up for labour saving tools and flashy sales presentations. I can open an IDE (usually Eclipse with plugins) and get going creating an Orchestration, ESB routing path, Portal portlet, Rule Flow, you name it.
However,… when the dust settles there are broadly 2 major problems with the current implementations of these Enterprisey Tools.
-
I need to put these creations into a project version control system. Why is this ‘the trouble’? Well these tools create an assortment of xml configuration file, java code, .properties, .blah and a proliferation of other unfathomable artifacts. I don’t know what is specific to my machine, specific to the IDE layout, what is test code - I short I don’t have a scooby doo (clue) what these files are - the documentation is much help either. I end up checking the lot into source control and then the fun starts when my team mates try to merge their changes with mine when they also have no idea of what these files are. For the record I don’t ever want to use the in built version control system. Why? Because, there will be usually more than 5 separate tools with there own source control systems and this quickly becomes unmanageable.
-
I need to be able to compile, package, build, deploy (remotely), run test and release to a release system working software from a continuous integration system. This system needs to run periodically and autonomously (that is without any human intervention). This system most like doesn’t have a graphical subsystem (windowing interface) it is likely a big bad *nix machine (sans X). I can not run the IDE on this machine. I also don’t want to install the IDE or indeed the server components on this machine. I don’t want to install this software on the machine because it is a huge overheadand keep the versions in line with the project (which can last up to 2 years). On a typical project this could mean installing 6 IDE and 5 servers on the continous integration servers and upgrading and patching each of these 3 to 4 times.
So here is my plea to the tools industry (you know who you are):
-
Everything that can be done in the IDE should have a corresponding ant task
-
Anything that can be done though your server console can be done as an ant task (or scripted in some way which can be call from ant).
-
All the ant tasks should be in a jar file and this jar file should have documented dependencies (ideally as an Ivy or Maven dependency file).
-
Do not impose your jar file directory hierarchy on me for the ant task (you know who you are).
-
Every file that your IDE plugin creates should be documented, what it is, what it’s structure is and what every part of that structure means. If you need help understanding the level of detail look at the hibernate mapping documentation for an exemplar
-
And whilst I’m asking please don’t insult me by telling me this isn’t important - it is. This is very important.
Update: whilst trying to find my way through the borkedness of one product I stumbled upon this blog entry describing some of the problems I am hitting with one product. This article was written in Nov-2004 and it seems that things have moved on very little since then. BEA, in this case, still use OS environment variables such as CLASSPATH and PATH rather than allowing them to be specified at the task level in an ant way. They still bundle a whole lot of crap in their weblogic.jar and reference still more from the manifest that confuses builds. Why is the ant API included in their server environment classpath?!