Mike`s Blog

My default project set up for Maven-based Java projects:

/pom.xml
Parent pom for the project. This is in a parent folder, as some CI servers don't like the build to be in a module, e.g. foo-build\pom.xml

/foo-api/
API, domain model, common utilities, exceptions, value objects. Best: No dependencies to anything else other than the Java types. Acceptable: Dependencies to very very very common stuff like commons-logging or to a enterprise-wide our-commons.jar

/foo-core/
Service implementation. Dependencies: To some components. Best: no other dependencies, esp. not to glue code such as Spring.

/foo-conf/
Deployment and Configuration resources, bundles as jar for archiving purposes.

/foo-ejb/
Enterprise JavaBeans (SLSB, MDB). This also contains the glue code, e.g. the Spring Application Context and Configuration.

/foo-ear/
Enterprise Archive, only necessary for deployment.

/foo-sar/
Service Archive, only necessary for JBoss deployments.

/foo-tests/
Integration tests, excluded from the parent pom and normal build lifecycle (e.g. using a maven profile), because they need life remote services and databases.

Is your set up similar? If not, let me know your thoughts on why another structure might be more suitable in other situations.

• Comment (1)
• Trackbacks (0)

TddMeter gathers the average time it takes me to fix failed unit tests. I installed the plugin a few days ago. Currently, i'm working on a new project, mostly on documentation, prototyping and the core model - test driven of course

I mention that, because working on an existing project or legacy code has a different amount of unit tests and the lifecycle is different. Working in the open countryside will have a faster test-cycle, while the documentation, analysis or prototyping phases are usually shaped by having no test cycles at all.

The TddMeter plugin shows the following stats for my last two days (since my last restart of Eclipse):


The time between a test failure and the implementation of a fixture is approx. 22 minutes.
Don't know if this is a high or low value, but it sounds okay.

Let me know your stats!

• Comments (0)
• Trackbacks (0)

OSGi bundles let you specify exactly which version of a dependency is required:

• no version specified - every bundle exporting your requested packages will satisfy your dependency


• exact version: [1.0.0,1.0.0] - only the bundle which exports packages with v1.0.0 will satisfy your dependency


• version range [1.0.0,1.2.0] - bundles which export packages 1.0.x, 1.1.x and 1.2.x will satisfy your dependency


• version range [1.0.0,2.0.0) - bundles which export packages 1.0.0 up to 1.9.9 will satisfy your dependency, but bundles exporting package 2.0.0 and higher won't


When specifying a version dependency, you need to know which version of a library is compatible with your code. You can be very strict and specify an exact requirement, or you can be tolerant.


• Comments (0)
• Trackbacks (0)
• Continue reading "Dependency Versioning"

Today I released v1.0.0 of the E-Payment module Saferpay for VirtueMart 1.0.x. Hopefully it's of help for people who want to integrate the swiss E-Payment solution provider into their VirtueMart shops.

• Comments (0)
• Trackbacks (0)

This is a follow up to Playing with Spring WS:

When defining the target namespaces, be aware of the following passage in the Spring-WS tutorial:

We start our WSDL with the standard preamble, and by importing our existing XSD. To separate the schema from the definition, we will use a separate namespace for the WSDL definitions: http://mycompany.com/hr/definitions.

The importance is that you use different namespaces for your XML Schema and for your WSDL target namespace. If they're both the same, the endpoint mapper won't find your endpoints.

Thanks Marco for pointing to the documentation. We tried half an hour to make it work with the same namespace and then decided to use separate namespaces. Then it worked.

• Comments (0)
• Trackbacks (0)