New Location

My website has moved to http://www.jasonwhaley.com. Please visit there for the latest and only remain here for legacy content.

Sunday, November 30, 2008

The Elegance of Netbeans

I have been an Eclipse user for probably 90% of the time I have done anything with Java. I started with Eclipse because at the time I began with Java in late '05, Eclipse had released a seemingly polished version 3.0 the year before, and my only other free option was Netbeans - a fact that remains true today, in terms of full featured ide's. Netbeans 4.x at the time I tried it didn't seem polished, was clunky, and had literally no useful plugins. Eclipse, on the other hand, had plenty. The only advantage I felt Netbeans ever had was in the basic EE web development realm, where writing webapps using plain old servlets and jsps was a tad bit easier and did not involve Eclipse's WTP, which itself was a plugin not quite ready for prime time.

Now, let us fast forward three years. Up until a few weeks ago I would have still considered myself an Eclipse user - despite the fact I have not written much Java code this year at all. I even half defend Eclipse in front of a bunch of Intellij Idea fanboys on irc (these tend to be the worst of the ide zealots). But there was a bit of a buzz building back up around Netbeans again. I heard it mentioned several times on the Java Posse podcast and saw talked about with a bit more frequency on irc, forums, and news sites. I decided to give it a whirl this weekend.

What I discovered was an ide that seem extremely polished, had useful plugins, and outstanding Maven2 support. m2eclipse is nice but feels convoluted. Netbeans maven integration, on the other hand, was about as simplistic and direct as one could have imagined it - there isn't even a need to run a `mvn netbeans:netbeans` or something similar to generate a Netbeans project from a POM. The ide also has profiling built in, which I haven't checked out just yet, but is a big win. Ultimately, there was just something fresh about this ide that I have not experienced with eclipse and with my quick trial of a rather buggy Idea 8. In addition Netbeans seems to have great support for other languages (ruby, c, etc.) that also felt a bit clunky in eclipse, and seems non-existant in Idea 8, from what I can gather. But ultimately it comes down to freshness - but I could not pin-point exactly what it was that was so fresh about it.

Then, probably after 3 hours of use, the source of that freshness hit me. I work on an OS XMac now, and I use it now mostly out of elegance. The UI on OS X for pretty much everything is simplistic, direct, beautiful and functional for 95% of things, and the remaining 5% is made available if you are the power user type and enjoy keeping a bash terminal open at all times, like myself. Netbeans 6.5 feels exactly like it is a native, prebundled OS X app. The look and feel is polished, the menus are grouped and nested in logical fashion, and the preferences dialog does not feel like labrynth - changing the editor font or adding a jdk is about as simple and direct as one could ask for.

My original plan was give the lateat Idea release a whirl and see if I enjoyed it, but I have pulled a complete about face and have switched my trial over to Netbeans. Unfortunately, the 3rd party Android plugin for Netbeans is not feature complete like the Eclipse one and I will be using much more of the Atlassian suite soon which has plugins for eclipse and not Netbeans, I'll still probably keep Eclipse as my primary working ide. However this won't keep me from doing all of my other work in Netbeans if at all possible.

So to Sun, I say congrats for putting a very nice product out on the market in the ide space.

Thursday, November 20, 2008

Installing Sources In Maven

A friend of mine was asking how to actually install the sources of a maven project to a repository. Downloading the sources of other dependencies is easy enough - all that needs to happen is the addition of the -DdownloadSources=true argument to your mvn goals. But how do you allow other projects who depend on your artifacts to do the same. The answer: Maven's Source Plugin. Essentially, all you need to do is
mvn source:jar install
for your projects source and
mvn source:test-jar install
for your test source of your project and viola! The sources are now in the repository.

Tuesday, November 18, 2008

Bad Appserver, No XSD!

This past Thursday I experienced quite a snafu with a certain application server distributed by Day Communique (CQ).

I was in the midst of a late night deployment involving other unrelated applications. Any work involving CQ or our code used in CQ itself was not to be touched - only a separate web application that happens to be housed in the CQ application server. This was supposed to be a relatively painless deployment, as such.

While I had some downtime in the middle of the deployment, I peeked into some of my non-work related irc channels, including ##java on irc.freenode.net - a channel dedicated to java programming that is normally raucous and condescending by day but rather calm by night. In trying to help folks there, we quickly discovered that java.sun.com, which is the source of all downloads and documentation related to java development was unresponsive to http requests.

Then at 4AM a nightly backup of a production server and the authoring application (the part that allows content editing) kicked off. Knowing this was already to happen mid-deployment, this production server was already taken out of the production rotation. It, however, did not come back online, thus meaning we didn't have any fail over for the server that was not backed up. Frantically searching the logs while a couple of engineers and QA folks started pounding at the other apps, I couldn't figure out what happened to this one server. About three minutes later I inspect the Author - it too failed to restart. None of the typical application logs were even writing to their logs. "What the hell" was pretty much the only thought going through my mind - nothing on this server has even changed!

Then I and a colleague take a quick look at the actual application server's log and notice these lovely entries:
18.11.2008 01:09:02 *WARN * servletengine: Unable to locate internal resource: /
resources/xsd/web-app_2_5.xsd
18.11.2008 01:09:02 *WARN * servletengine: Entity unresolved: publicId="null", s
ystemId="http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"
18.11.2008 01:09:07 *WARN * servletengine: Unable to locate internal resource: /
resources/xsd/javaee_5.xsd
18.11.2008 01:09:07 *WARN * servletengine: Entity unresolved: publicId="null", s
ystemId="http://java.sun.com/xml/ns/javaee/javaee_5.xsd"
18.11.2008 01:09:07 *WARN * servletengine: Unable to locate internal resource: /
resources/xsd/javaee_web_services_client_1_2.xsd
18.11.2008 01:09:07 *WARN * servletengine: Entity unresolved: publicId="null", s
ystemId="http://java.sun.com/xml/ns/javaee/javaee_web_services_client_1_2.xsd"
18.11.2008 01:09:07 *WARN * servletengine: Unable to locate internal resource: /
resources/xsd/jsp_2_1.xsd
18.11.2008 01:09:07 *WARN * servletengine: Entity unresolved: publicId="null", s
ystemId="http://java.sun.com/xml/ns/javaee/jsp_2_1.xsd"
18.11.2008 01:09:07 *WARN * servletengine: Unable to locate internal resource: /
resources/xsd/javaee_5.xsd
18.11.2008 01:09:07 *WARN * servletengine: Entity unresolved: publicId="null", s
ystemId="http://java.sun.com/xml/ns/javaee/javaee_5.xsd"
Laughter ensues - we have an application server, in production, hosting a critical app, that fails to start up with a fairly vanilla installation because it didn't bundle an xsd locally (which is a no-no) that is referenced in the declaration of typical xml files and can't fetch them from java.sun.com for xml parsing. Epic fail.

Thankfully within the next 30 minutes, java.sun.com became responsive again and the production server and its Authoring counterpart could be restarted. This isn't the first time something with Communique has made me scratch my head and say WTF, and it won't be the last. The sad part here is that Communique is the one lone commercial, non-open source product that we use internally and we pay good money for it. Yet we are subject to things like this...