From the userguide:

You can also skip the tests via command line by executing the following command:

mvn install -DskipTests

If you absolutely must, you can also use the maven.test.skip property to skip compiling the tests. maven.test.skip is honored by Surefire, Failsafe and the Compiler Plugin.

Skiptests is a feature of surefire, while -Dmaven.test.skip is a feature of maven itself.

The Java Health center is

very low overhead monitoring tool. It runs alongside an IBM Java application with a very small impact on the application’s performance. Health Center monitors several application areas, using the information to provide recommendations and analysis that help you improve the performance and efficiency of your application. Health Center can save the data obtained from monitoring an application and load it again for analysis at a later date.¹

It’s also pretty easy to install ².

1. Add the healthcenter.jar to %JAVA_HOME%/jre/lib/ext folder
2. start whatever application with -Xhealthcenter
3. Default port is 1912

The openingscreen:

and for instance the profiling tab:

References:

1. Java Health Center- a low overhead monitoring tool - http://www-01.ibm.com/support/docview.wss?uid=swg21413628
2. Installing the Health Center agent - http://publib.boulder.ibm.com/infocenter/realtime/v2r0/index.jsp?topic=/com.ibm.rt.doc.20/healthcenter/com.ibm.java.diagnostics.healthcenter.gui/docs/installingagent.html
3. IBM Support Assistant -  http://www-01.ibm.com/software/support/isa/

Other:

1. Feature overview: http://www.youtube.com/watch?v=5Tcktcl0qxs

Let me start with my biggest discovery: the book is written about jBPM3 and not the newer jBPM4. This is not mentioned on the Packt publishing site. Too bad, a jBPM4 book is still missing in the offering.

Conclusion

PRO:

• Probably the best developers book about jBPM3 so far. Compared to BPM With JBoss jBPM, this book is aimed more for developers and goes further into the technical details.
• The book brings beginners to an advanced level. It does not bring advanced users to a further level.
• I would advice beginner jBPM developers to start with this book. It emphasizes on getting the basics right but does not hide the more advanced features.
• The explanation is good, providing context and sufficient examples.

CON:

• Their is definitely a language impedance for the writer. Sentence are basic, language constructs are poor and almost all the sentences start with “You’ll see” or “You will”. Very sad to see this poor editorial from Packt Publishing. Clearly no review by them, and I blame them and not the writer.
• Some content is noble, but also beyond the goal of this book. Chapters 1 & 2 are not interesting to jBPM Developers. They cover a motivational speech about why you should care for open source, what is BPM and how to create your own BPM engine.
• Some must have advanced topics are missing: integration with test frameworks, exception handling for example.

As stated, I do recommend this book for new jBPM developers since it does provide a rather good learning curve for new developers. Don’t expect this book to be a reference, therefore it is much to verbose and not advanced enough. The userguide of jBPM is a better reference.

Kind regards,
Andries

Students can find the slides below:

• How well should something be implemented? Is it OK if it just works, or do I need to refactor and make it more “generic”?
• When is it done?
• …

The rule I live by is as following:
If I write code, I make it so that I, or anybody else, could reuse that code with ease.

This means:

• Write good documentation, mostly on WHAT it does, not HOW. It’s a whole lot easier to read code if you know what the result should be. It’s not easier to read how something works, then read the code and then guess what the desired outcome should be.
• Write clear code. Hacks or fuzzy lines should be refactored. Hacks tend to get more hackish with old age.
• Create loosely coupled code. Code with a lot of dependencies can’t be reused. Make it a little more abstract if you have to.
• Use generic names. Don’t write classes named MyProjectDataValidatorUtils.
• Don’t hard code project specific stuff. Use property injection instead.

This does NOT mean:

• Write code that can do a lot more than is needed for the project.
• Premature optimization. If I know my project will only have 10 entities, I’m not testing for a million…
• Over document it. We are still developers. Write to many and you won’t really read anything at all six months from now.

If done a handful of projects and I reuse a lot of stuff from old projects. The fantastic thing is, that these building blocks have the tendency to improve over projects. Every project needs specific functionality, and by adding those to existing blocks you end up with some really powerful, reusable parts.

Regards!
Andries

You can find the demo’s at the jbpm svn.

Regards!
Andries

You can register here.

I’ll be presenting on J-Spring about this integration of jBPM 4 and Spring. More information about it can be found here.