Impressions: Hamburg – Alster

Hamburg Alster 2011Hamburg – Alster 2010

View from hotel – 11′th floor

Click to enlarge

Experience with YED


A while ago I tried to find an alternative piece of modelling software for projects where M$-Visio is not the project standard and I’m free to choose the modelling software I use.  Four years ago I found YED and I’ve never looked back. The latest versions support BPMN Graphs and can be used to model topologic network plans, a variety of UML Diagrams and much more.

It’s worth a try. Check out the Examples.

Gradle vs Maven vs Ant

Since I’ve done a lot of stuff with Ant and worked in many projects where maven was the weapon of choice, project sizes have  differed massively. As a result I’ve seen a lot of  different configurations, varying from simple standalone applications to complex multi-module projects. Maven looks really suitable for simple projects, or projects where everything should fit into one jar/war file. The problems begin with multi-module Management. Cross-References are not resolved the right way, the build is slow during cyclic references and cache and index reloading causes trouble. If you are using your own repository manager (Nexus, for example), the index and caching problems become much more significant. There are also a few issues with a central settings.xml where version numbers can be stored. Values are not resolved and the behaviour is not reproducible. Scary! The poorly managed primary / third-party repositories are also problematic. They force you to use excludes and old library versions if you don’t use a repository manager. The biggest problem with maven, however, is that it forces you to deal with the given project structure and the build life-cycle. There are a lot workarounds you can use (like running ant tasks in maven), but none of them feel right. Features like build automation and automatic deployment are supported but due the complexity of enterprise systems, you’ll end up with a bundle of ant tasks in the XML structure of the pom.xml. A few people also complain about XML as being the wrong language to write the build file in, but since I’ve written a lot of spring-wiring bean files, xml feels wordy, but it’s not a problem for me. So I tried to migrate the pom.xml of some of my projects to gradle. It worked fine, aside from the bad IDE support from Eclipse/STS. The resulting build file is about fifteen times smaller and looks pretty readable. WAR bundling and the Jetty task to run the application worked fine. The only problem I discovered: The dependency ‘com.sun.xml.ws:jaxws-rt:jar:2.1.4′ does not resolve its necessary dependencies. I fixed this issue by downloading the distribution and put them into my “lib” folder. Maybe I’ll try to fix it and show my experiments.

Painful JPA 2.0 CriteriaQuery

JPA 2.0 offers a lot of nice features such as support for extended maps, collection mappings, automatic removal of related objects (orphan), configurable pessimistic locking and caching. But in my opinion, there are also downsides, such as the bloating CriteriaQuery which turns a simple JPQL query into a six line monster. The first time I had contact with JPA #2 was while reading IBM Developer networks “Dynamic, typesave queries in JPA 2.0″. Since there are already such great articles like “Don’t repeat the DAO” out there, I was a little confused about the focus of the article from IBM. Typesafety is great, if it’s applied in a generic way! The advantages and drawbacks of so much more code? Due raw type usage / type erasure no runtime checking for the type is possible. Secure / Deterministic refactoring may be to blame. Viewing type problems at runtime shouldn’t be an issue, since the application is being tested properly. Most IDEs offer features for String lookups during refactoring which can help with the refactoring issues. JPQL Queries tend to have a readable structure. The CriteriaQuery API looks like the opposite is the case if the query is a more complex one. In my opinion the price for such a “typesave” Query is too high; while the JPQL Query is based upon SQL and offers readability, the Criteria API looks verbose and bloated. I prefer to write good old JPQL Queries.

My first Blog

I decided to start my own blog! Don’t know if anyone will read it, I just wanted to share some thoughts and opinions. As one of the leading blogging websites, I picked WordPress as the means to this end.