Can you recommend any magazine?

Maven supports two debug modes: the Generic and the Surefire. If you want to debug maven itself, one of maven’s plugins, or a maven project, use the Generic Approach. If you want to debug a test in your project launched by surefire, use the Surefire Approach.

Surefire Approach.

• Create a new Java Project and call it “Maven Debug”. This Project will never have any source code in it, it is just a shell for attaching the debugger.
• Create a debug configuration: Run -> Debug Configurations and then right click on Remote Java Application and select New launch configuration. Call it “Maven Surefire”.
•  On the Connect tab click the Browse button and select the “Maven Debug” project.
• Set connection properties to localhost and port 5005. This is the port on which Surefire waits for the debugger.
• The connection type is Standard (Socket Attach)
• On the Source tab add all projects that have any Maven source that you want to debug.

Now let’s do the actual debugging.

• Select break points in the code you’re are going to run. Note, you cn select only code in your test classes. It won’t work on classes outside the test phase.
• In your command line, append the following switch to your maven command: -Dmaven.surefire.debug. For example, to debug the tests run by the maven lifecycle install do mvn install -Dmaven.surefire.debug
• Wait for maven to pause its execution and display the message: Listening for transport dt_socket at address: 5005
• Attach the debugger to the running maven by selecting the “Maven Surefire” debug configuration created above. Your debugger should stop at your breakpoint.

Generic Approach.

• Follow the instructions, presented here. The only instructions that worked for me. They are very similar to the Surefire Approach.
• Note: use Maven 2.0.8 or higher. The, you don’t need to write your own maven debug script. It’ll be sufficient to use the shipped mvnDebug script.

If you ask what are the benefits of going OSGi with Spring, read Adrian’s article Why should I care about OSGi anyway? 

• In the database — I’ve read this suggestion somewhere that you can set a trigger. However, not all databases support this feature. Moreover, database independence is crucial. Setting a trigger as Java Annotation or property would be more convenient.
• AOP — Write a Spring aspect that intercepts calls to Hibernate/Database and add the current time-stamp to the appropriate field.
• JPA @Version — This was a promising approach. Unfortunately, edited objects were not updated but newly inserted. See a description here.
• JPA Listeners – by implementing JPA listeners and using @PrePersist annotations this would be the most convenient and elegant way to implement the requirement. For some reason, entity listeners don’t work with AppFuse/Hibernate. Speculations point to Hibernate not supporting this feature.
• Hibernate Interceptor – Similar to an aspect, one could implement a Hibernate Interceptor. However this approach bind the application to a specific Persistence Framework and prevents other persistency options in future. While this is a nice decision, one has to bear in mind that JPA is a small subset of features provided by each persistence framework. Hibernate is by far much more expressive than JPA and offers much more support than other frameworks. I fear that in the future, I will decide in favour of Hibernate as it offers much more support.
• Manual — probably the worst solution is to leave the developer in full control. That is, he has to care that a timestamp is added and modified whenever an object is edited. This approach error-prone as changing the modified time-stamp can be forgotten. Morever, there can be a delay between setting the modified time-stamp and the actual persist action to the database.

The only option left is to give Spring AOP a shot. Let’s go!

This problem is actually addressed by Lucene. However, in a web application were the domain model is a key part of the business logic, Lucene is not easy to integrate. Problem such as structural mismatch, synchronization mismatch, and retrieval mismatch have to be solved. To bridge the gap and to provide the best things from both worlds, Lucene is now integrated into Hibernate. Search queries can be issued against the database or against Lucene in a transparant way. Search performance increases a lot and the developer has a very comfortable way to state queries and to provide results.

I consulted AppFuse’s User group and found a thread which described my problem. Unfortunately, no good solution has been proposed. The author pointed to a Jira Issue in which a work around is described, but well, it’s not a good solution. A few other guys joined in the discussion, but none was able to solve the problem.

Today morning, I digged a bit deeper in it. I recalled March 18. One thing you have to know about Maven is, that by default, prior to compiling, it checks for new jar versions every day and downloads them. So I looked into my local m2 repository and found out that Maven downloaded the latest surefire plugin. I went to its web site and found a Jira bug report describing exactly the problem. However, the problem is still unresolved. But now that I know which version of the plugin caused the problem, I told my Maven project description not to use it and to use a previous version instead. Just add the follwing snippet to your build plugins section:

Guess what, it solved my problem. And that makes my day.