Total Pageviews

Monday, February 26, 2007

Run IntelliJ IDEA 6 with JDK6

If you want to boost your IDEA startup performance and the loading of your projects try to run IDEA with JDK6. There is an entry in Jetbrains support forum describing this under
It really kicks asses!
But be aware: Please note that running IDEA under JDK 1.6 is not officially supported yet

Friday, February 23, 2007

How to install a Perl module on Debian Linux

Just in case you want to install Perl modules on a Debian Linux system:

Search for modules Tk and Curses:

apt-cache search Tk | grep perl
apt-cache search Curses | grep perl

Install the found packages:

apt-get install perl-tk
apt-get install libcurses-perl

List all Perl modules:

dpkg -l 'lib*-perl'


egrep '^Package: lib[a-z-]+-perl' /var/lib/dpkg/available

Thursday, February 15, 2007

MAIDEA moving to Mevenide project

MAIDEA, a plugin that integrates the Maven2 build functionality into IntelliJ IDEA, is moving into the Mevenide project hosted on Codehaus.

The goal is to provide one plugin that supports all aspects of Maven's functionality (e.g. dependency management, repo browsing, running builds, etc.).
The code base of the Mevenide2 IDEA plugin will consist of the formerly known Maven Reloaded plugin and MAIDEA.

Wednesday, February 14, 2007

Maven 2.0.5 released

The Maven team released version 2.0.5 of their software today. Checkout the release notes at:

Sunday, February 11, 2007

Dependency Management and package architecture in Java programs

When using Maven you get a lot of reports out of the box. Version control reports, code quality reports, javadocs, etc.
This blog entry focuses on code quality reports, especially on the JDepend report and other ways of measuring and controlling code quality.

Why is dependency management so important?

This is a question that will arise sooner or later in almost every software project. Good dependency management is the key to maintainable software. In conjunction with well designed package architecture the dependency management will save lots of time and money when it comes to maintain and take care of a released software.
Maven enforces you to think about your project artifacts and dependencies before you start to implement your software. Because it follows the principle: One artifact per Maven project. Thus you are able to separate different tiers of your software into small artifacts which can be compiled, tested and released independently of the release of the full software system.
Think of a web enterprise application bundled in an EAR archive. The application usually consists of several artifacts:
  • Foundation JAR archive(s)
  • EJB JAR archive(s)
  • Web application archive (WAR)
Every artifact can be tested independently from the others. Of course integration tests are often necessary to make sure the whole thing is still working. But it lets you concentrate on one point of your software system.
Things that must be avoided at any time are cyclic dependencies between those artifacts. For example, a method from an EJB JAR calls a method from a foundation JAR, and another method from the same foundation JAR calls an EJB JAR method. This would produce a cycle between the foundation tier and the EJB (Business Logic) tier. Maven is able to detect cycles and refuses to compile a project that contains cycles.
Even harder to detect are cycles between vertical slices in the same tier or cycles between logical layers of a physical artifact. Those cycles can be detected using JDepend. But JDepend is very limited and a System Architect is not able to define a logical architecture which can be controlled and oberved through the complete life of a software system. In this case you might want to consider the use of SonarJ or Sotograph. Why using a software to detect cycles? Because it is almost impossible for a human to see when a cycle creeps in!
Maven enforces you to keep an eye on your software design by providing a JDepend report out of the box. With JDepend you can control the couplings between packages and the stability or instability of particular packages or even cyclic dependencies between packages in your artifact.
If this is not enough for you and you would like to be able to define an architecture which can be controlled and observed by a Software Architect and/or the Software Developers have a closer look at the above mentioned SonarJ. It is recommend for middle-sized or big-sized software projects and can easily help you in maintaining and controlling your software design.
With SonarJ it is easily possible to declare allowed dependencies and directions between logical layers and vertical slices and to see when those dependencies or access directions are violated.

Thursday, February 08, 2007

Timer problems in JBoss with TimerBeans

Since I updated to JBoss 4.0.4.GA I randomly receive the following execption in one of my applications:

23:22:19,812 ERROR [TimerServiceImpl] Cannot create txtimer
java.lang.IllegalStateException: Unable to persist timer
at org.jboss.ejb.txtimer.DatabasePersistencePolicy.insertTimer(
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(
at sun.reflect.DelegatingMethodAccessorImpl.invoke(
at java.lang.reflect.Method.invoke(
Caused by: java.sql.SQLException: Unique
constraint violation: in
statement [insert into TIMERS
at org.hsqldb.jdbc.Util.throwError(Unknown Source)
at org.hsqldb.jdbc.jdbcPreparedStatement.executeUpdate(Unknown Source)
at org.jboss.resource.adapter.jdbc.CachedPreparedStatement.executeUpdate(
at org.jboss.resource.adapter.jdbc.WrappedPreparedStatement.executeUpdate(

It turns out to be a problem with a TimerBean.
A solution is described in the JBoss JIRA:
To make is short:
The "localDB.script" file ($JBOSS_INSTALL_DIR/server/default/data/hypersonic) must be cleaned up by deleting all (or the particular) timer entries (INSERT INTO TIMERS ...). Those entries are inserted by JBoss and represent timers which should be executed after a server crash. Unfortunately the ID generator for inserting unique timer ids doesn't generate unique ids :-(

Saturday, February 03, 2007

Creating a SSL-certificate for a server

If someone is in need of 
creating SSL certificates for his 
server (eg. at home), he might find
the following script very helpful.


echo Delete old private key
echo Create new private/public-keys without passphrase for server
openssl genrsa -out $PRIVATE_KEY 1024

echo Create selfsigned certificate
# From man req:
#  -x509
#    this option outputs a self signed certificate instead
#    of a certificate request. This is typically used to
#    generate a test certificate or a self signed root CA.
#    The extensions added to the certificate (if any) are
#    specified in the configuration file.

openssl req -new         -days $VALID_DAYS         -key $PRIVATE_KEY         -x509         -out $CERTIFICATE_FILE

echo private-keyfile is $PRIVATE_KEY
echo server-certificate-file is $CERTIFICATE_FILE


Update: There is a short way in generating a new SSL certificate for your home box:
sudo make-ssl-cert generate-default-snakeoil --force-overwrite
This works on my Ubuntu box.