Wednesday, September 17, 2008

Shell scripting my way out of IDE hell

The last few days I've been fighting with a Java project I've been working on. I've inherited this project, and the original developers created it in NetBeans. When I tried to configure the project using a tool other than NetBeans, I ended up with hours of headache and so I learned my lesson. Stick with NetBeans.

Only, NetBeans isn't so easy to stick with (for me). First, it runs at a painfully slow pace on my laptop. Second, I'd get inconsistent results - one day, the app would work just fine, the next I'd get a dreaded NoClassDefFound error on a class that I'd never touched. And then today, it started freezing. Just freezing, I wouldn't do anything to cause it. Argh. My blood pressure goes up just thinking about it.

Now, this isn't all NetBeans fault by any means. The app I'm working with was designed using EJBs and a variety of Web Apps that make it way heavier-weight than it needed to be. The result of this architecture is that a redeploy appears to be necessary after every change. Why, just, why, should I have to redeploy the entire app if I want to change something as trivial as a CSS deceleration? Oh, and it was also designed by programmers who named both session beans they authored SessionBean1 (not SessionBean1 and SessionBean2, but both SessionBean1). Need I say more?

While fighting with some random exception in NetBeans (where, I'll have you note, the cause wasn't filled in. It just said: EJB5070: Exception creating stateless session bean : [{0}] - notice the {0}, where the actual message should go), my buddy suggested I manually deploy the .ear it built using Glass Fish directly. Interesting, use NetBeans to edit and build, and manually deploy outside of it - hmmm, I hadn't thought of that.

At first I used Glass Fish's web app to do the deployment, but then I remembered that it comes with a series of command line tools. Again, hmmm, that could be handy.

Then, while dealing with NetBeans freezing, I realized that it was just kicking off ant to do the build process. What would happen if I tried building from outside of NetBeans too? I gave it a try, and built flawlessly.

Then it hit me - why was I slaving through all this pain? I shut down NetBeans (whoo!) and wrote the following two scripts:

ASADMIN='/c/Program Files/glassfish-v2ur2/bin/asadmin.bat'
ANT='/c/Program Files/NetBeans 6.1/java2/ant/bin/ant'

"$ANT" dist

if [ $status = 0 ] ; then
    "$ASADMIN" deploy dist/app.ear
    echo "Build failed, skipping deployment"

ASADMIN='/c/Program Files/glassfish-v2ur2/bin/asadmin.bat'
ANT='/c/Program Files/NetBeans 6.1/java2/ant/bin/ant'

"$ASADMIN" undeploy app

I then pointed Emacs to the source tree and went back to some old school coding (which isn't really that old school, considering it's how I write my php apps every day). When I wanted to deploy the app, I ran: ;

When the app didn't work right, I checked server.log for an exception stack trace. Turns out, Glass Fish actually produced pretty clear errors.

At first it was a little disorienting using Emacs when I had started to grow accustomed to the many near-magical features of NetBeans. For example, I couldn't just jump around the source tree, but had to know where I wanted to look. But a remarkable thing started to happen - I began to actually wrap my head around how all the components of this app went together. Rather than just trusting the IDE to guide me, I had to find my way myself. The result: I was forced to figure stuff out, rather than hitting Undeploy and Deploy over and over again till stuff started working.

Do I think you should always code Java in Emacs and not Eclipse or NetBeans? Of course not. I just know, that in this case, Emacs got where I needed to go a whole lot faster than either of those apps. And not only that, I got a better understanding of the app at the same time.

No comments:

Post a Comment