Once upon a time there was a young, well-meaning developer who decided to solve everybody’s problems by using two tools. There was the traditional tool and the non-traditional tool. The non-traditional tool was the more powerful of the tools but because our star wanted to ensure everybody had that warm-fuzzy feeling he made a conscious decision to support both tools during development. The idea was to not impose too big of a learning curve on the development staff. You see our mild-mannered developer (the aforementioned hero who will hereafter be referred to as Mr. Applesauce) was one of a minority in his new company. Most people were well versed at “the existing tools” and had no knowledge/desire/passion to invest in learning something different. Then there were a number of people on Mr. Applesauce’s team that were new to all of the tools necessary for development. It made perfect sense to begin with tools that others in the organization could assist with should any of the team members get confused and should our tool-selecting main character (who we will refer to as the “Voice Of Jamaica” for the remainder of this text) win the lottery, buy a yacht, then hit an iceberg after sailing out to sea thus rendering him unable to return to his desk the following month and resume his earlier analytical duties… because Heaven knows he would never abandon his day job on lottery winnings alone.
All things equal (forgetting those things that fall on the left and right sides of greater-than and less-than symbols), our story continues with the Voice Of Jamaica (pon-di right hand side, ya know?) trying to smash the two tools together and create the illusion of the original more widely used but inferior tool. What he actually succeeded in was smushing two problems together and creating the illusion of a single solution to both ends. Jabber the door-to-door salesman (earlier referred to as “The Voice” but now assuming a new alias for the mere purpose of… oh I dunno just flow with the story for now, ok?) later collaborated with another really eager developerto solve their fifth and final problem. As it turns out problems three and four were more copies of the former already solved problems which brings us to undisclosed problem number five. Because Jabber was soo John Blaze (he should now assume this as a monicker) he figured out how to use the brilliant idea not carefully explained in the first paragraph above to fix issue number five. Things went ok for a while as the illusion obscured the view of the cancer spread from the beginning. Others tried to warn Mr. Blaze (remember from like two sentences ago when I renamed Jabber?) that there were problems afoot but he was too hot-headed. (No pun intended, unless you thought the connection was clever in which case absolute pun… big pun intended.) In the long run the problem manifested on the desk of management as something completely different than what it actually was. Problems have a way of doing that. A problem can begin life as a child briefly left unattended by your upstairs bedrooms, evolve into several once-inch-thick Ticonderoga pencils stuck in the toilet, and end life as sewage-like water seeping from the ceiling onto your 32″ LCD screen. By the time the water starts shorting out your Panasonic screen you’ve lost complete context of you lack of responsibility to the youth and begin laser focus on the people who sold you the cheap widescreen that can only tolerate a few drippings of sewage water. I mean, c’mon! Don’t they lab-test these things for real world conditions? I bet you could go swimming with a Sony Bravia strapped to your back and still catch Leno after hours but oooh noooo… Panasonic has to opt for the cheap non-doodie-resistant material!
Where did we leave off? Oh yes, Mr. Clementine! (Aka: John Blaze) The moral to our story, because there has to be a moral or else what’s the point of the story… is one who serves two masters is easily distracted, unable to server either. I believe it was probably Confucious that mentioned that, or maybe it was in the book of Matthew somewhere. Yes you can call Ant from Maven and it’s very practical to do so in many use cases. However you cannot properly/easily/pragmatically/accidentally make a Maven build system out of an Ant build system without re-writing the entire “build.xml” for individual target access. The second moral here is that you should not deploy a multi-component based project completely from source. You can certainly build individual components from source. You can even take the time to build all the components from source prior to packaging them up and deploying them. However you should not attempt to make your deployment based on the source of all the individual components. How about that for lessons learned? And you thought I was talking about apples and Clementine oranges!
This message was brought to you in part by:
Jet Brains: Bringing fine IDEs to even finer developers.
The Eclipse Foundation: Without them there’d be no reason to design another IDE that people could actually use without first going to college. Ok, that’s harsh and Eclipse, believe it or not, is a really good tool. It’s just a little heavy on the swiss army knife sauce. Yeah I got love for Eclipse.
Curious Bunnies: I almost hit one of these suckers on my way home from work the other day. He was all hopping in the middle of the road redirecting traffic into potential guard rails and looking like one of those Geico squirrels giving high-fives for claiming innocent lives.