Soapbox Rants and Raves

I seem to work on a variety of Java applications and find that unit testing is one of the most varied (implementation-wise) pieces of the development process. These applications, created by different development staffs, many which have evolved over the pass few years are all very unique… kind of makes me wonder why? That is a topic for another post!

One debate I always seem to encounter is around where to actually save the unit tests? Should we do in-package testing or rely on the public API. My preferences are pretty simple:

• Unit test should not be stored with the code, but rather created under a secondary source root. On my early projects, I created a sub-package under each package, called test, to manage the relevant files (tests and data). I later realized that I could simplify the Ant build process and enable in-package testing by creating a separate source tree. I have seen projects commingle the actual source code, unit tests, and even the test data files, all within the single source tree. This defaults the testing strategy to in-package testing, and discourages (or even prevents) API testing. I find this approach rather messy and unclear. This approach also complicates the Ant build process; at some point during the process, the unit tests, supporting classes and files should be separated from the actual deployable content.
• I like to name my secondary source root tdd. I know it is not widely practiced, but my hope is that if the developers see that TDD directory every time the open up their IDE, the concept might actually wear off! Maybe someday, one developer (hopefully more) will actually be challenged to write their unit tests first. With Eclipse and jUnit 4.x annotations, I seem to always start with my unit test, and sometimes even refactor code from the unit test into the actual class; kind of a high-bread TDD process, but the thought is always there!
• I also prefer the public API testing strategy verses in-package testing. This line of thinking always takes me back to the Testability Explorer. The concepts behind this metric enforce the idea public API testing and is worth a quick read. Add the Spring Framework to the mix, enabling dependency injection and I see little need for in-package testing. This is typically accomplished by creating a “test” package as the root of the secondary source tree, with sub-packages reflecting the package hierarchy of your classes to be tested. I truly believe that defaulting to in-package testing allows the developers to be very sloppy and even unaware that they are testing a specific internal implementation, rather than externalized behavior presented by the API… This is VERY bad practice in my opinion.
• If there is a need for in-package testing, then the sub-package structure of the classes to be tested can be recreated under the secondary source tree, maintaining a clean separation between the source and test cases. These test should be considered an exception to the norm, rather than common practice. I would hope for a 90-10 or 80-20 ratio, with a majority of the test falling under the test package root (in-package is the minority).

I am kind of tied to Eclipse as my IDE, but do play with NetBeans every so often. I think I could switch to NetBeans, my only real requirement is that the IDE must have Emacs key bindings; some habits are just too hard to break! NetBeans looks like an pretty good tool and seems to be very responsive on my Ubuntu box; I especially like the way it manages plug-ins.  One interesting thing that NetBeans does (maybe a little better than Eclipse), is manage unit testing. NetBeans will automatically create the secondary source tree, but seems to default to in-package testing. It is very easy to add the additional test package into the package structure to enable API testing. I also like the way that NetBeans separates the Test Libraries from the regular Libraries. I’m not sure how well this would work when you use a tool like Ivy, but does make it more obvious, as to which libraries are used for execution verses unit testing… If you do happen to generate a unit test from an existing class, NetBeans will generate more code than Eclipse. I’m not sure how useful this code is, but it does try to create the object under test, invoke the get() methods and perform assertions on the returned values. Might be more noise that it is worth, and anyway, you should be writing the unit test first!

The bottom line is that Unit testing should be easy and valuable. If it becomes too hard or complicated, it might be time to re-address how the unit test strategy is being implemented.

This was making me crazy the other night… I did not spend too much time on it, thinking is was just me. But, after upgrading my laptop and encountering the exact same problem, I knew there was more too it. It seemed like only the cancel buttons actually worked; all of the next and finish buttons did absolutely nothing, other then beep!  I soon realized that I could use the tab key and press enter to move to the next screen; but that did not make me very happy.

A quick Google search turned up several people with the same exact problem. It was kind of interesting. The Ubuntu developers did not want to take responsibility for the problem and said it was an Eclipse issue. The Eclipse community said they never had to do anything special for Eclipse to run on Ubuntu; it was looking like a stand off! I did find the official bug report filed with Launchpad.net, it says the problem is resolved. However, without overriding the following variable, Eclipse is not very usable.

export GDK_NATIVE_WINDOWS=1

It also appears that this problem is affecting many other tools on the new 9.1 release as well. This simple fix will get you back into action, without having to wait for the real fix.

The Eclipse developers did a really nice upgrade to the Plug-in manager in the new Galileo release. Managing plug-in sites seems much easier and cleaner with the new Available Software Sites menu option in the main preferences area. Not really a new feature, but seemingly more obvious, is the ability to import and export update sites to and from your team mates. I have exported my settings and linked them to the XML file icon on the left. Simply download the XML file and import them into Eclipse and you are ready to go. I can’t believe I never used this feature in the previous versions!

Also, don’t forget that you can also have Eclipse automatically find new updates for you. This is not a new feature either, but one that I always seem to forget! I just hit the Check for updates option every so often; not nearly as convenient! You can find this option under the Install/Update preferences panel as well.

Once you have your software sites configured, it is time to install or update your configuration.  Under the main Help option, select Install New Software.  You can select multiple plug-ins for installation  or use the new Work with: option. You can filter your plug-ins based on a specific site’s configuration file. I’m not exactly sure why I like this better, but the old multi-tab Ganymede version was just too busy. I think the new screens are much cleaner and easier to work with.

I have to give credit to a co-worker who overheard me complaining about Eclipse one day… Ever since upgrading to the Ganymede version of Eclipse, the launch buttons for executing and debugging applications and unit tests were tied to the currently active editor. This was so annoying, I could not believe the Eclipse developers changed this behavior. Every time I clicked on the button, Eclipse would ask me what I wanted to do…. No, I don’t want to execute the XML file I was looking! No, I don’t want to execute the random Java file that I just fixed; I want to run the last unit test!

Pre-Ganymede versions of Eclipse simply ran the previously launched application or unit test. It was so convenient to just click the button and rerun the test. Apparently, I was not smart enough to look at all of the available options in the preferences menu; I conditioned myself to click on the little arrow next to the launch buttons and select the test I wanted to run from the menu. To my surprise, there was a new menu option that controlled the behavior of these buttons! Unfortunately, the default behavior is the un-desirable one, in my opinion; but with a quick click of the mouse, the world is right again! Hopefully, this little tip will make your Eclipse usage a little happier and smoother too. Thanks Jason!

I might be in the minority, but I’m just not that excited by this release of Eclipse. I started using the RC3 version for real last week, and have had no issues at all; it seems very solid.  I attempted to use with the first couple release candidates, but they did not seem to play well with the Subversion plug-ins. I’m sure it was user error; it could not have been that messed up! For whatever reason, Eclipse completely toasted my work area (multiple attempts) after every commit. Needless to say, I did not even bother using them.  I have Eclipse integrated with the Spring IDE, Checkstyle, PMD, and Ivy plug-ins. I heavily use the Web Tools Platform for deploying web applications to Tomcat.  At least for what I have been doing lately, there is nothing to get me really excited. I think the best part is, that everything still just works! I notice a new little feature every so often, but nothing that says that’s a keeper! I have been using the Implementors plug-in for many years and was glad to see they finally implemented this feature within Eclipse. It works pretty well,  but they only implemented half of the functionality! With the Implementors plug-in, you can click on the interface method and ask to see all of the concrete implementations.  You can, sort of, get the same functionality through the type hierarchy view, but not as nicely. After seeing the Open Implementation feature, I thought this was a new feature too; I did not know that you could just click on a URL and have it open up in the browser, kind of handy!

One other thing that seems new, is the ability to search using partial camel-case entries. If you are really lazy or can not spell worth a crap, then you will probably use this feature a lot. Simple type in mixed case letters in the entry field, and Eclipse will automatically match to those classes. I thought the bold-ing of the matched letters was a nice touch.

There are two features that need some work, especially when you are moving between (upgrading) Eclipse versions.

1. I thought the Clean Up and Save Actions functionality were excellent additions to the Ganymede release. I still can not figure out why I have to enter my configurations on both option panels. You can import/export the configuration on the Clean Up panel, but not on the Save Actions panel; you have to re-enter everything. I understand that some people might want different behaviors, but you should at least be able to import/export your settings on the Save Actions panel too; allowing us to reuse the other panel’s settings. I thought for sure this would have been fixed, small  bummer.
2. The Content Assist Favorites drives me crazy, especially because I’m a big jUnit believer/implementer. Because I only use jUnit 4.x annotations and static import assertions in my unit tests, Eclipse is not smart enough to add the imports when I hit <CTRL><SHIFT>o or ask for the content assist. Maybe I learned something new tonight, from this blog.  I typically enter all of the jUnit assertion signatures (method names only) that I typically use. It looks like their might be an easier way, just by specifying the Type, I will have to try this tomorrow! Personally, I think jUnit assertions should be added by default, but that is just me!

If I’m missing out on a new killer Eclipse feature that was added to Galileo, please let me know! I don’t want to take away any of the great work that was done on this release, unfortunately, I don’t use any of those new additions! But I don’t think you can go wrong with this upgrade.

I was looking for a development build of the IvyDE plug-in for Eclipse tonight and I stumbled across the Apache Hudson server. You have to check this out. Pretty cool, Hudson running over 150 jobs!  Their build farm consist of both Solaris and Ubuntu servers. What I found most interesting was how they used Hudson for creating an Eclipse update site. I subscribe to the Hudson mailing list, summarized here, to follow what is going on with the project. People seem to use Hudson for a variety of different purposes, such as a cross platform testing tool and even as a deployment tool. I have only been able to get people interested in Hudson as a “Cruise Control” replacement…. but at least it is a good start!

This site also demonstrates how multiple projects can be linked together, triggering builds of dependent downstream projects.  I’m not exactly sure how these jobs were assembled, but at a high-level, Ivy and IvyDE each have its own build loop (job). Each job is responsible for creating build artifacts. After a successful build of either job, a third job is triggered which creates/updates and Eclipse update site.  Pretty slick. (As any FYI, the dev plug-in looks better, new presentation and several new new options)

Another small plug for Continuous Integration. We recently set up something kind of cool (trivial, but cool)! As we continue trying to convince the powers that be, to move away from Weblogic towards Tomcat (or even JBoss), we found a really nice little feature. Since Tomcat and JBoss can hot deploy a new version of the WAR file, just by noticing a difference on the file system, combined with the fact that we can spin up a Tomcat instance in about 2 minutes, we actually created an auto deployment mechanism.  Our Weblogic environment seems so cumbersome in comparison…. We could have built the WAR and deployed in in our build loop, but that would have minimally added another 25 minutes to the loop (let’s just say we have an interesting deployment process). With Tomcat, we did a one time deployment to the location of the WAR file inside the Hudson workspace. Now, with each series of check-ins, we build the WAR as normal and Tomcat instantly deploys it, in seconds! If we were a little more sophisticated, we would write some jUnits to bang against it, making sure we did not break anything or create any new dependencies.  Maybe I will throw that in during my next project!!! I know this integration was possible before (with Weblogic), but no way as simple!  Even better Continuous Integration… on my last project I had Ant spin up an embedded Jetty web server, ran my jUnits against the Clover instrumented code, and finally had Ant shut down Jetty…. Pretty slick, from a code coverage collection perspective…

I’ve ran across several blogs that listed their favorite Eclipse plug-ins.  Since I am such a huge Eclipse fan and am always preaching about the power and benefits, it seemed like a good idea for me to document my preferences and experiences. First, you need to start with the Eclipse Java EE version, probably the Ganymede version (3.4), but Galileo (3.5) will be released next week. This Eclipse bundle will give you more than you need, but is the best starting point. Out of the box, Eclipse has many useful features:

• Mylyn – Task focused development support; here is some background information.
• Web Standard Tools – Gives you all of the nice editors for XML, HTML, JSP, etc.
• J2EE Standard Tools – Provides support for J2EE projects, such was the Servlet and EJB.
• Remote System Explorer – Excellent plug-in for accessing remote systems. It enables you to remotely edit files and provides shell access, including SSH.

Here is my personal Top 10+ list of Eclipse Plug-ins:

Just a random link of several more plug-ins, http://www.plentyofcode.com/2007/07/most-useful-top-50-eclipse-plug-ins.h6tml There were a few plug-ins on the list that looked interesting, maybe you will think so too. Make sure you read the comments!

This Eclipse feature has been around for a couple years, but seems to stay hidden from most developers; probably because they have not had a chance to take advantage of the Dynamic Web project type. It seems like once a project is setup, nobody ever wants to change it! The Dynamic Web project type is used in conjunction with the Eclipse Web Tools Platform (WTP) plug-in, which has been on my “Upcoming” list for some time now…

<HISTORY>I was a huge fan of the MyEclipse plug-in suite a few years ago; it was a predecessor to the nicely bundled Eclipse distributions that can be downloaded today. MyEclipse provided a very elegant Eclipse / Weblogic integration capability; as well as many other nice features that otherwise were difficult to manually enable. I worked with many different teams and it was always a hassle to convince them to purchase or convert their projects to the structure required by MyEclipse. As I became more familiar with the Ganymede release and the maturing Web Tools Platform plug-in, this Eclipse bundle seemed to be a much easier to sell and better alternative. MyEclipse is still a very popular and well put together product; be as I recall, it always took them too long to catch up with the current Eclipse versions, which I was fond of using as well.</HISTORY>

To use WTP, your project needs to have some additional features, namely Facets. Facets are used to define characteristics and requirements for Java EE projects. Originally, only Java EE projects had Facets; but this seems to be changing. I recently added some J2EE Module Dependencies to a web project, Eclipse enabled Facets in the simple Java project included as a dependency. To convert an existing project to a Faceted project, you need to manually modify your .project file. It is best to only enable Facets and let Eclipse add the additional nature; these natures will be added as you enable extra characteristics. To convert a Java Project to a Web Project, modify the .project file and add the following two lines.

<nature>org.eclipse.wst.common.project.facet.core.builder</nature>
<nature>org.eclipse.wst.common.project.facet.core.nature</nature>
 

You will not notice any visual difference in your project after making this change. However, if you open up your project’s properties and search for the word facet, you will see a new configuration option. At this point, you can select the Dynamic Web Module option and configure your runtime environment (Tomcat, Jetty, etc).

If you have successfully converted your project, you will see a small globe appear on the project folder icon. You can now add the project to the Servers view and easily deploy the project in your locally configured runtime environment. I have glossed over some of the WTP setup, but will cover that in another post. I thought it was important to explain Facets; I had previously wasted significant time, manually converting projects to Dynamic Web projects. Unfortunately, the manual approach only worked about 50% of the time. Once I learned about Facets, it made my life a lot easier!

FYI, the (S) on the folder, next to the globe, indicates a Spring IDE plug-in enabled project.  If you are developing Spring-based applications, you have to install this plug-in; it makes creating and managing your context files many times simpler.

I only played with Galileo for about 10 minutes and I am already very intrigued. Based on my last post, I wanted to see if I could get Ivy and Eclipse to work better together and explore the new features. The first difference appears to be the way that plug-ins are installed and managed. Eclipse 3.4 significantly changed the way plug-ins were installed and it looks like they are changed again. Plug-in management was never as smooth as NetBeans. NetBeans provides a fully integrated solution for searching through available plug-ins, with click and go installation. The new Eclipse implementation looks promising, maybe not as polished as NetBeans, but a step in the right direction. As shown to the right, you can now view all of the available plug-ins in a much more controlled and usable approach. Managing additional software sites is much cleaner than before too.

At first glance, there seems to be a lot of small, subtle changes, rather than any big, must have features. The Eclipse release process appears to be taking longer and longer; the first milestone release was last August! This is the first time I have not jumped on the milestone builds, preferring to stick with the Ganymede release for my daily usage. Another small change is the way the network proxy panel works; it actually seems more complicated than it was before! They finally added (or re-implemented) one on my favorite plug-ins,  the “open implementation” option. How could that feature not been part of Eclipse before this? It is an absolute necessity when programming with Spring. Overall, I think Galileo looks a little more polished than before; I will start using it for my daily work and try to find more interesting new features to report on!

A new to me feature… After adding the IvyDE plug-in to Eclipse, the next step is to add the Ivy managed dependencies to the project. I found a new project properties panel, Java EE Module Dependencies. I thought this was a new feature, but it appears this feature was available in Eclipse 3.4 too. I hoped this was the answer to my Ivy problem! The panel allows you to pick other projects and/or their class path entries to be added as web library dependencies; it suggested that these dependencies would be resolved at deployment time. I gave it a try, but unfortunately it only half worked. The dependent project part worked perfect; making a JAR file out of the secondary project and copying it over to the exploded WAR’s WEB-INF/lib directory. This seems like a good solution when working with external projects, especially when you are activity integrating them into your primary project. The unfortunate part is that Eclipse still completely ignored the Ivy dependencies; not copying any of the Ivy resolved JAR files to the WEB-INF/lib directory. What a drag! I will have to continue my quest for a workable Ivy / WTP solution!

I was searching for some information on using the Eclipse IvyDE plug-in and found a post that reminded me of some work I did last summer. For the most part, I’m happy with the way the IvyDE plug-in works, but sometimes you have to be a little tolerant of its usability issues. Every so often, IvyDE seems to forget about my configuration and refuses to add libraries to the class path. My only option is to remove Ivy Dependency Manager and re-add it to the class path.  One problem that I’ve been unable to solve, is the integration of an Eclipse Web Tools Platform (WTP) project and Ivy; I cannot get the Ivy resolved libraries added into a “Dynamic Web Project”, making them available to the Tomcat. I have tried a dozen different configurations and settings with no success. Hopefully, I will get this working in the near future. If anyone has this working, please give me some tips!

The real thought behind this post was echoed in this post by Daniel Spiewak, So Long WTP, Embedded Jetty For Me. I was really fired up about Jetty last summer. When compared to my experience developing Weblogic-based applications, the utter simplicity and flexibility of Jetty was amazing. I was working on a custom Servlet-based web service framework and decided to do my development with Jetty. I created a very small Java program that configured Jetty to deploy my Servlet, in about 20 lines of code! The best part is there was no special Eclipse project type, no special environment, and zero deployment work; making debugging and testing especially easy.  I never used the word embedded when I talked about Jetty, but that was exactly what I wanted. I always deployed in the Weblogic container because of our corporate standards. I should have explored this a little more, further highlighting the point that Weblogic and all of its complexity is truly unnecessary.

Following the BEA Bible, you end up with specific machines, specific file systems, specific networking, and hardwired clusters. Combine that with an environment that is highly controlled, it can take a dozen change control tickets and multiple days to bring up a new instance. Not exactly what I call agile or responsive. How cool is would it be to just drop a WAR file on a machine (any available machine), launch java to bring up a web server, add it to the load balancer and instantly expand your processing capacity? Pretty powerful idea, I think.

Embedding a web server is a good idea when building a web-based application, both for development and operational reasons. A good example is the Hudson Continuous Integration tool. Hudson is distributed as a single WAR file that you can pop in any Servlet container; but it also includes an embedded web server. This approach is becoming more and more common, as several open-source and commercial products are shipping their products with embedded web servers. The real benefit is flexibility. It literally took me seconds to get Hudson up and running; no messing around with Tomcat, no configuring security realms, no anything! It allowed me to focus on Hudson, rather than the environment to make it work. Down the road, if I want to deploy Hudson in the standard application server environment, it should be an easy switch, This is quite different from my recent experience installing a few open-source code review tools; installing multiple Python packages, configure an Apache web server, setting up database servers, etc. I don’t think I have to say much more; the better choice is pretty obvious.

It is pretty hard to beat the Eclipse WTP – Apache Tomcat integration as a development environment, but directly embedding Jetty into your environment (no WTP) would make the environment even simpler. I have been trying to encourage teammates to develop from a container independent perspective, demonstrating higher productivity with no additional risk to the project. If we can move from large, monolithic applications to smaller, self contained services, the attractiveness of Jetty goes way up. The flexibility of running a moderately sized collection of small, independent services, verses a small tightly coupled clusters of monoliths, has to be an attractive architectural vision.

Unfortunately, many corporations don’t eagerly embrace open-source software solutions, preferring to pay for name recognition and guaranteed support. I personally feel that Jetty is a viable option, but it seems to be relatively unknown to most developers. Apache Tomcat and JBoss have a much higher exposure level, giving them more perceived viability. Jetty is no slouch, check out the Powered by Jetty page. Hopefully, this and Daniel’s post demonstrate there are alternatives to the J2EE Silver Bullet, and that we don’t really need to do everything by the J2EE book. There are a lot of simple alternatives out there for us to take advantage of, all we have to do is keep an open mind!