redredred

Powerful ORM frameworks like hibernate and Ibatis and more recently JPA based ORM frameworks like Toplink, Hibernate and openJPA have taken a great deal of drudgery and error prone code out of the average enterprise application codebase. Many IDEs now provide powerful tool support for writing and maintaining code based on these frameworks. One effect of all this has been to move attention away from the database and into code, particularly in instances where developers are using automatic ddl generation from their ORM framework.

In such a situation, developers often don’t think about the effect that changes to their java code are having on the underlying database. Before there has been an initial release this may not necessitate migration of production data, but it can lead to large amounts of time wasted when changes in code necessitate schema changes, particularly if these changes clash with schemas other developers have established in their development environment. After an initial production release it can lead to serious problems if developers alter domain objects which are mapped using ORM frameworks. Simple XML or Annotation changes can wipe out or make redundant whole segments of the production database when released into the wild, or completely alter the semantics of existing data.

There is no doubt that a new discipline is required for developers when writing code using ORM frameworks. Paritcularly where there are multiple developers and potentially multiple production releases (pretty well every agile project I have ever known). This discipline should focus on the database schema that ORM frameworks are generating. Such schemas need to be versioned in the same way as the codebase is versioned. Luckily a tool called Liquibase exist for exactly this problem.

Liquibase provides for the creation and maintanence of database schemas and their data. I have not yet used it to make changes on production databases but we have been using it in development and it has had a very positive effect on productivity as developers no longer have to spend time working out why their tests are no longer working only to eventually discover that it is due to data changes conflicting with their existing schema.

Liquibase manages schemas and data through change sets and the database itself. It stores the change set ids in the database along with a checksum for the change set so that it can determine if the change set has been altered, invalidating it against that database.

With Liquibase in place the database can be generated and/or updated without the use of the ORM frameworks auto generation of DDL, in fact it is essential that this be turned of. For Spring applications a data migrator bean can be configured to automatically generate or update the database on startup of the application context and check that the schema is valid for application data mappings. If this is not desirable Liquibase has Ant targets and Maven goals that can be executed.

Flex applications are reasonably easy to write, and they certainly build themselves a lot faster than standard web applications which need a rich user interface. Testing them is a bit of a problem though. I looked as ASUnit initially, but the whole framework was so Windows-centric that I gave up in disgust. I could tell after a very short time that even if I got it working on my Mac there would be no way to run it in an automated build loop.

After that I started playing with FlexUnit. This framework is much more generic and quite simple to use. The most confusing thing about it is that there seems to be a FlexUnit project on Sourceforge as well as Google code and they don’t appear to have anything to do with each other. I couldn’t make head ‘nor tail of the Sourceforge one but the version on Google code, which appears to have some Adobe support behind it was simple to install and use and this article gives quite detailed instructions about how to use it.

Testing in Flex is still not always that easy, even when you have a reasonably easy to use framework like FlexUnit. You still have to write code which can be unit tested. This is the real value of rigorously testing your code. You have to write your code in such a way as it can be tested. When you do this your code becomes more loosely coupled and more highly decomposed. This leads to not only more testable code, but to more re-usable code…”Vive le testing”

Once you have tests you need a constant integration loop to run your tests and keep you honest. Initially we didn’t think this would be possible, turns out we were wrong. Antennae is an open source project on Google code which addresses exactly this problem. A detailed explanation of how to install and use it can be found in the Flex Cookbook. There is a fair bit of mucking around involved, but with a bit of determination you can reasonably easily get your Flex codebase to build and execute it’s FlexUnit tests in a constant integration loop.

Below is a list of eclipse 3.2 plugins which I like and whos URLs I am constantly forgetting. hopefully I will never need to google these again

1. The Maven 2 plugin provides the ability to search the various Maven repos for dependecies. It also allows the prject to be built by the Maven builder, automatically manages your POM and will attach source if requested. This plugin was a little buggy initially but seems to be fine now. If you are building your project with Maven 2 I really recommend this.

Update site: http://m2eclipse.sonatype.org/update/

2.Emma plugin for eclipse. This provides full coverage analysis as a plugin for eclipse. It allows you to run your test suite under Emmas coverage analysis tool and provides immediate feedback as well as code highlighting to indicate sections of code which have not been visited by tests. This plugin is really useful for keeping you honest.

Update site: http://update.eclemma.org/

3. a) Subclipse is a subversion plugin from tigris. It is free and provides pretty much all the same features you are used to seeing for CVS, but for SVN. It also has some nice features for navigating into branches and branching with uncommited code, etc

The eclipse update site for this is: http://subclipse.tigris.org/update_1.4.x

b)Another Subversion plugin for elipse is Subversive. i changed to this plugin recently because it seems to resolve conflicts in a manner more like the old CVS conflict resolution tool. The icon set is not quite as nice as the Subclipse set, but it seems to perform slightly better for conflict resolution.

Update site: http://www.polarion.org/projects/subversive/download/1.1/update-site/

4. Veloedit is a Velocity template editor. Very basic, but better than nothing when you are writing velocity templates.

Update site: http://veloedit.sourceforge.net/updates/

5. XFire plugin. This is quite a useful plugin if you want IDE support for xFiring service endpoints.

Update site: http://dist.codehaus.org/xfire/update/

6. Spring IDE. If you are using Spring this is a must-have plugin. Provides bean file support for dependencies as well as making sure that class names are valid.

Update site: http://dist.springframework.org/release/IDE

I just wanted to make a note of this URL in case I forget where to configure the hudson SVN access. It was a pain to work this out:

http://<hudson-url>/scm/SubversionSCM/enterCredential

This topic has waxed and waned in importance for me (mostly depending on how our team is going with meeting deadlines) but it is never completely out of my mind. Coding style, maintainability and robustness have always been more important to me than speed and so I am not a great fan of the Web application drag and drop development frameworks I have seen. Even though it is a quick way to get a form setup, it almost invariably leads to nasty code which can be harder to tidy up than just doing the thing yourself in the first place.

That being said, in a competitive marketplace, for a company writing custom applications to be viable you need tools and code libraries to speed up the development process in ways which don’t reduce quality. Frameworks like Spring, Hibernate & the new JPA EJB 3.0 go a long way toward speeding up the development process for enterprise class applications but the MVC part of the equation has always been a sticking point in my experience.

Spring MVC solves one part of the problem, that of backing web forms with plain old java objects (POJOs) rather than the Struts approach of having action forms with String fields which have to be manually converted in the action to resolve to POJOs. This is done via property editors, Simple types such as Integer and Date are provided and users can implement custom logic to do the conversion on more complex, user defined types.

The next time consuming problem is UI layout, validation and display of messages to the user. In my opinion, small UI concerns and tricky validation issues burn inordinate amounts of time in web based applications. The solution to this seems to be a well constructed tag library which is terse and has flexible and easy to extend validation. The need for this tag library is what drove myself, rob and others at Groupware, when I was working there, to develop the SpringLayout framework, essentially an extension to Spring MVC with a highly coupled tag library and validation framework.

SpringLayout is still in it’s infancy but already has proven of great worth in data gathering applications, short-cutting the time it takes us to develop our applications. I will be interested to see whether other developers get the same degree of usefulness out of it as we have so far and to get there feedback on the developer experience.

I wonder what other developers think about RAD for Web Applications?

Recently we have been attempting to move away from manually managing libs for each project and move to a central repository for manging our jars and dependecies. Maven 2 seemed like the ideal tool for this and since it seems to have such a large body of support we thought that it would be reasonably easy to integrate into our current development processes. We even thought we might get quite a bit of leverage out of the other plugins available for Maven 2 which would allow things like automatic site generation for the project and documentation of dependencies.

Unfortunately getting Maven 2 integrated into our current development processes was anything but easy. We usually build Web applications and we use the MyEclipse plugin for eclipse to automate and speed up many of the repetitive tasks. Auto-deploying wars and hot-swapping code is one feature we consider absolutely critical to our rapid development process. The following is a description of how we eventually got this working, and now can in fact get setup quicker than we could our old way.

1. First make sure that Maven 2 is installed and that it is in the path (see the Maven install instructions if you can find them).
2. .Configure the M2_REPO variable in Eclipse to point to your maven repository (usually /.m2/repository). This can be configured in Eclipse under windows->preferences->Java->build path->Classpath
3. Next, I have found that is easier to just follow the Maven folder conventions than to try and get maven to follow yours. This means that the normal src folder becomes src/main/java, all resources and configuration files go in src/main/resources, and the web root becomes src/main/webapp the test tree follows the same structure and becomes src/test/java and src/test/resources. In order for MyEclipse to live with this and do a hot deploy you need to tell the web deployer that your web context root folder is /src/main/webapp, this can be done when you give a project web capabilities but if your project already has web capabilities then you will need to modify the .mymetadata file in order to change it and restart eclipse.
4. obviously your project needs to have a valid pom.xml in the project root. Under the part of your pom put the following: <plugin>
   <groupid>org.apache.maven.plugins</groupid>
   <artifactid>maven-eclipse-plugin</artifactid>
   <configuration>
   <buildoutputdirectory>src/main/webapp/WEB-INF/classes</buildoutputdirectory>
   <downloadsources>true</downloadsources>
   </configuration>
   </plugin>
5. this tells eclipse to build to the classes folder under your web root WEB-INF folder (where they need to be for a hot deploy)
6. Navigate to your project root on the command line and run mvn eclipse:eclipse this should build your .classpath file according to your pom.xml and even attach source code where available.

Most people should be able to hot-deploy as normal now using the MyEclipse server tools, however i have noticed some people have problems with servlet-api.jar and jsp-api.jar conflicts, if that is the case then the following steps should fix that:

1. Right click on your project and go to the properties>java build path>libraries You will need to look through this list for servlet-api.jar and jsp-api.jar, remove them and add the J2EE library (You will need to do this each time you run the eclipse target or else your servlet-api.jar and jsp-api.jar will get deployed to your web server and may interfere with the one it already has in it’s classpath
2. Next, still under the project properties item go to MyEclpse->Web->Deployment uncheck the ‘workbench default settings’ and ‘Jars in web Projects user Libraries’

you should now be able to do a normal MyEclipse hot-deploy…