Project Versioning and Release - Best Practice

• A new project starts usually as version 1.0.0.0-SNAPSHOT. Three number versions (1.0.0) are also used but, for example, ServiceMix OSGi server requires three dots.
• A new feature/fix is frequently developed on the trunk and committed there when ready for release.
• Release. It is usually done on the trunk (does it have to be? what if someone commits changes in the middle of a release?). It is all done by maven release plugin, (more datails here). Is done in two steps: mvn release:prepare i mvn release:perform. What maven does during a release:
• up the version by 1 (often on the last numbered position: 1.0.0.1)
• build, maven-release and deploy to organization's repository if any
• tag it in SCM
• up the version number on the trunk (it will become 1.0.0.1-SNAPSHOT)

Notes:

• On the trunk, we have always -SNAPSHOT versions
• Each release has a tag
• If the maven release plugin fails, it usually leaves the pom.xml messed up on the trunk.  Make sure to fix the version and scm tags. 
• Alternatively,  a new feature/bug fix can be developed on a branch.  In this case, the branch needs to be merged to the trunk, when feature/bug fix is ready. I guess, this merge should happen before the release.
• In multi-module projects,  if you want to give the same new version to all modules, add set the option autoVersionSubmodules to true (in parent pom?  where?). Otherwise, you'll be asked for the new version for each module.

Why TDD Rather Than Traditional QA's Writing Tests

First, I describe what is TDD. Then, I present a story that lead me to writing this article.  But if you don't care about stories, just skip to Conclusion and Resources


What is TDD?
I'll describe TDD not with my own words but with a few selected excerpts from this resource:

• The practice of maintaining automated unit test suites has gained widespread acceptance over the past decade to the point where most developers today either engage in some amount of test writing or at least feel bad for not doing it.
• To prevent regression, developers must provide a set of tests that exercise an application top-to-bottom and end-to-end (front-end to back-end), but anecdotal evidence suggests that even automated tests covering as little as 50% of the code can effectively guard against regression in many applications.
• Competent developers either conform to a test-first discipline in which small test harnesses are built to exercise an API before the API itself is even implemented, or else employ a code-a-little-test-a-little (CALTAL) approach in which each unit of code developed is tested immediately after its compiled.
• Most build systems, such as ant, provide direct support for running test suites as part of the application build process, and continuous integration systems, such as Cruise Control or Hudson, kick off such builds automatically each time code is committed to the team's version control system

Situation
Recently, I ran into project OpenSatNav. It's an open-source version of AndNav2, that is navigator application for Android OS based on OpenStreetMap. Great project, still pretty young, but dynamically expanding. I watched a few issues being fixed by the developers involved, and noticed that the process of findind a solution was a bit erratic. There were several attempts to guess a solution, and guesses were not perfect, but then there were a few better guesses.  Some NullPointException bugs cropped out after a few days and were fixed. Still, some issues were reported, but never reproduced, so by the token "it doesn't show the problem anymore, so let's close this issue", the issue has been closed. What was obvious to me, is that the solution is not necessarily correct. The testing was done manually and without even any systematic approach.

Spring into Action
It was obvious to me that what was definitely missing, was the automated testing, especially unit testing. I tried to step in and encourage unit testing. The idea of TDD, or any unit testing that I proposed several times was for the project team like a fairy tale about a bad wolf. But the developer team and the project lead were friendly and not exclusive.The lead-developer on this issue, responding to my requests, did include a well defined test-scenario with the fix code. I thought: it's not bad, I'll step in and write a unit or functional test for this fix. I have experience with TDD for Android, Java, GWT and Flex projects.

Result
It took me time (I have a full-time job and four children ages 4 - 19, plus, I took this as an opportunity to review the currently best practices for testing for Android OS), but finally I got to writing the test. And here's what I have found, which may be very well what also you experience is in this matter.  While writing a unit or a functional test for your own fix or new feature is a fun and a relatively straightforward activity, writing a test for a code written by someone else, is neither much fun nor simple. You end up reverse engineering the whole part of the system that surrounds the part where the fix was made.

Conclusion
Simple. Write your own tests. This, was for me always fun and an enlightening experience. And, I think, my design and coding have improved because of the tests I wrote. Tests for my own fixes.  Tests written immediately after I have written the code (CALTAL), or even just before I have written the code.

Resources
The following are useful for getting quickly to speed with TDD, esp. for Android OS development:

• A very nice and concise intro article in Wikipedia.
  
• Writing Unit Tests for Android
• Android: simple guide to unit tests
  

Developing Flex Applications with Java Middle-Tier

Intro
In my job we are using Flex with Java to develop web applications that support the activity of the agency I'm working for. It's my first experience with Flex and I'd say, I'm duly impressed. I had experience of developing using GWT and I must say, that Flex is an equally good tool.

A Simple Way
Just follow this tutorial.

Tools Used
We use the following toolset:

• eclipse with FlexBuilder plugin (plugin is not free)
• jBoss
• Java for back-end
  
• LCDS to communicate between Flex and Java (not free, but there are free alternatives: BlazeDS and the LCDS Express is also free, I think).
  
• Cairngorm pattern for Flex client structure
  

Tips and Gotchas

• A great intro to Cairngorm (and Flex itself) is one by David Tucker.
• He is using ColdFusion for the back-end, so switch to this or this for how to do it with Java.

The Cairngorm pattern for calling a remote service is a bit complex. Here's how it goes:

• In the main mxml file (the one where you define mx:Application): instantiate the ServiceLocator: . The id "services" is irrelevant, it seems. And instantiate the FrontController.
  
• Let say, the command LOGIN is to be handled by the back-end. Dispatch the command by initiating the LoginEvent and calling dispatch() on it.
• Each event is mapped onto a command in the FrontController. Let say, in this case, onto a LoginCommand.
• In loginCommand, instantiate a delegate, say LoginDelegate and call the login(event)
• In LoginDelegate, obtain the service proxy using:
  ServiceLocator.getInstance().getRemoteObject("myRemoteObject");
  and call the login(args) on it.
• Now, two additional files need to be setup: Services.mxml and remoting-config.xml
• In the first one, Services.mxml, define a mx:RemoteObject with id="myRemoteObject" and the destination="myRemoteClass".
  
• In the second, the remoting-config.xml, define a destination with id="myRemoteClass" and the Java class package+classname in the source tag.
  
• In the Flex Server properties (access through project properties), set the Root Context as the /YourProjectName.
  

If you need to pass an object between client and the server, create two corresponding value objects (usually named *VO, like LoginVO), one in ActionScript in flex branch and one in Java branch:

• The ActionScript version, needs to have an annotation above the class definition: [RemoteClass(alias=org.sjb.LoginVO)].
• The Java version needs to be public and have public setters.

If you want to debug not only Flex (which is done the usual "eclipse" way), stop the JBoss server and start it in Debug mode. That's all that is needed.

Conclusion
Altogether, using Flex with Java is very simple. Enjoy it!

How to Deploy a GWT Application to Tomcat?

Intro
OK, so you have tried the GWT (Google Web Toolkit), decided that it's cool, and you created your first application, precisely a module. You have tried it locally on your development machine, using the hosted mode and, may be, in the web mode by using the Compile/Browse button on the hosted-mode preview window. Now, you can either deploy it to Google App Engine, which is a way to try it online free and easily (make sure that your app doesn't become the IP of Google! I haven't looked at the terms of use myself.) or you decide yo want to go for it, and publish it for real. You purchase a Java hosting plan (google for it; you can find some within $12/mo.), and you're ready to deploy your application to your Tomcat server.

Deploying It
I used this resource to help me with. Basically, follow the steps ( is the root of your GWT application,):

• create a staging folder (let's call it deploy)
• copy contents of /www/com.meography.EntryScreen into /deploy
• create /WEB-INF with folders classes and lib in it
• create web.xml file in WEB-INF. See the above resource for how to.
  
• copy contents of /bin folder to deploy/WEB-INF/classes
• copy all needed jars into deploy/WEB-INF/lib (you don't need gwt-user.jar nor gwt-dev-windows.jar, though)
• compress all of the conents of deploy folder into a zip file and rename the file to .war.
• upload the file to Tomcat, which can be done via browser using Tomcat manager, which is usually already installed for you by your Java hosting vendor. Once the upload finishes, the manager will show your application with options to Start, Stop, Reload and Undeploy it. The name of the app, is the base URL for your app.
  

Point your browser to the main .html file of the module (URL indicated by Tomcat manager + YourMainScreen.html). And, voila, you should be on. Well, if there are any problems, for example with your database setup, you'll find errors in the catalina.log file in the /tomcat/logs folder on your production server.

Re-Deploying It
To redeploy, after you have done some changes, simply repeat the steps above, but remember to preserve files you had to tweak or create for your production environment like web.xml and possibly hibernate.cfg.xml, if you happen to use Hibernate and use different database on your development machine and on your production server (Java hosting plan will usually have MySQL and PostgreSQL databases included). And, one more thing. I have found that I have to do Undeploy, upload the new .war file and then Deploy for the changes to post correctly. The reason may be, that GWT application is compiled into JavaScript cache files with random names, so the file names will be different each time you compile it, and so, just copying the new .war file over will not replace all of the old files.

Any feedback? Feel free to let me know.

Developing for Android Platform

Why Android?

I'm a Java developer. Yes, I could enhance my C/C++ skills, get an iPhone and develop for the iDevices. But, I guess, I wasn't motivated enough. Also, I'm a strong supported of open source development. So, first, I noticed OpenMoko platform. But their development slowed down and stopped. Never got to the point when I'd be able to get a phone and develop for it. Finally, I noticed the Google's Android initiative in late 2007. Yes, I'm afraid of humongous corporations like Micstosoft and now Google. Still, I didn't see a more attractive choice. So, I waited for Google to release the Android phone. I could switch to Windows Mobile platform, but this, somehow, didn't attract me. Finally, in Jan 2009, after living with Palm for good 7 years, and I'm a heavy user of the personal organizers (several years ago, I'd create my own notebooks/calendars, so they'd fit my needs; out of paper and cardboard; I did this for good 2-3 years), finally in Jan 2009, I decided it was time to do the move and I purchased a black G1 (for the picture and a story of my other organizers, see this blog).

Does It Fulfill The Promise?

In short, yes. Is it perfect? No. I can suggest several improvements of the top of my head, even just for hardware. And for software, too, of course. Would I recommend it? Definitely. Does it have a potential? Oh, yes, sure. This section could be a topic on its own, but, it will have to wait for another time. Let's move.

So, to Cut To The Chase, How Do I Develop for Android
Simple. The list of tools I use:

• Eclipse (3.4.2)
• JDK (1.6)
• ADT (0.8.0) - great tool. Can even deploy to the device over USB and monitor the app.
• Positron aka Autoandroid - for integration testing. Unit testing doesn't work that great for fat clients. This is a great tool except for a few hick-ups.
  
• jUnit - for the pieces that can be unit testing without reaching to your left year with your right foot.

Do you want more details, technical details? Sure. Here they're:

Where can I find some sample Android applications?
Well, one good sample is the Android platform itself. For example, to see the source code for the native Android calendar application, you can view it here.

Deploying onto the Device:

• an unsigned .apk file installs with a "Application installation unsuccessful"

• log a application crash,,, where can I find it? The ADT displays LogCat.

Using Positron aka Autoandroid:

• If getting an error about Autoandroid "java.net.SocketException: Connection reset" problem, either:
  
  • rerun the Android Application and run stories again or
  • application crashed on Android

• If you get error "Internal Error ... ShouldNotReachHere", do
  
  • go to the jUnit relevant run configuration, //Classpath// and remove the Android Library from Bootstrap.
  • do //Advanced//, //Add Library// and choose JRE System Library
  • add JUnit library the same way

Struts, Hibernate Development with Eclipse

I'm developing an web application to test algorithms for Romba-like devices. I have some algorithms in mind, that I want to test, so I decided I develop an application for the purpose of testing these algorithms or any algorithms.

I wanted to use Java standard frameworks, for now Struts and Hibernate and Eclipse as the. It took me some time to figure out what free plugins to use with Eclipse to add support to Struts and Hibernate. I looked for some time and finally found the following set of plugins:

• Tomcat plugin from EclipseTotale.com.
• Hibernate Core Plugin from Hibernate Team
  
• StrutsIDE - Project Amateras plugin
  

For DB development support I have used three:

• DB Development plugin (from Eclipse.org)
  
• QuantumDB
• Derby plugin (from Eclipse.org)

Probably the first of these would be enough.

A few notes:

• Tomcat plugin doesn't come with a documentation, but the website has a decent one. Plugin works nicely. Starts Tomcat in debug mode, unless user disables this feature in plugin preferences. Switch to Debug perspective and you can debug your application.
  
• QuantumDB is a well known plugin, but I had problems with it. I couldn't find in it the tables that were in the database. Possibly, I'll learn how to use it. DB Development plugin is easier to learn it.

I'm still in early phase of the development. I'll update this blog when I have more experience with these plugins.