Should Maven generate JAXB java code or just use Java code from source control

buildscode generationjoel-testmaven

We're trying to plan how to mash together a build server for our shiny new Java backend. We use a lot of JAXB XSD code generation and I was getting into a heated argument with whoever cared that the build server should:

  1. Delete JAXB created structures that were checked in.
  2. Generate the code from XSD's.
  3. Use code generated from those XSD's.

Everyone else thought that it made more sense to just use the code they checked in (we check in the code generated from the XSD because Eclipse pretty much forces you to do this as far as I can tell).

My only stale argument is in my reading of the Joel test is that making the build in one step means generating from the source code and the source code is not the Java source, but the XSD's because if you're messing around with the generated code you're gonna get pinched eventually.

So, given that we all agree (you may not agree) we should probably be checking in our generate Java files, should we use them to generate our code or should we generate it using the XSD's?

Best Answer

We have a similar situation here, but the schemas don't change that often so the Java doesn't need to be regenerated very often.

The way we deal with it is to create a new Maven project with just the schema files as source and generate Java code from that. We then deploy the generated Java as a jar to a local Nexus repository, but the only things that go into source control are the POM file, schema files, and any other necessary files (such as binding files). Any projects that require the generated Java get it as a dependency, from Nexus.

When the schema does change, the changes are checked in to source control, a new jar is generated and deployed to Nexus. Any projects that require the new version can simply update the dependencies to use the new version number.

The build server doesn't have to generate anything and the libraries are available for all teams to use, as dependencies in their own projects.

Our motivation to do it this way was that often many other teams need the generated Java for independent applications, and that once the schemas stabilize, they usually stay stable and don't need to be regenerated with every build/release.

Related Topic