Expected or Recommended usage of the Maven JAXB 2.x Plugin

I'm new to XML Schema and to JAXB and wondering what the best or expected approach to using the Maven JAXB plugin (http://static.highsource.org/mjiip/maven-jaxb2-plugin/generate-mojo.html)is.

I have a simple XML document format for which I've defined a schema. I'm primarily interested in reading a compliant XML file into Java, but I'll probably also want to add extra properties to the POJOs which won't be in the XML, but will be used at runtime.

By default the plugin places generated code into ${project.build.directory}/generated-sources/xjc. What I think I want to do is copy the generated code into /src/main/java/whatever and add to/modify the code to add my extra properties. When I change the schema, I'd then merge changes form the newly generated POJOs into my own ones.

The alternative is to tell the plugin to place the generated source directly into /src/main/java and to perhaps subclass the POJOs to add my own properties, but I'm not sure whether the marshaling/unmarshaling can still be made to use my extended classes.

Anyone have any guidance on which approach is more normal or what the pitfalls of each are?

In your place I'd leave the generated sources where they are so that the corresponding jar can be built by Maven without further configuration and put your custom code in a different project that depends on the first one. This ensures that everything is build in the right order.

It is your choice whether to derive from the generated classes or just use instances of them in your code, as attributes or, even better, local variables. Personally I'd avoid derivation; after all JAXB is just low level machinery you use to perform I/O in a specific format.

Most importantly: forget about modifying the generated sources; why introduce an error prone manual step in your development process when you can get the same effect automatically?

(To provide a slight variation on to Nicola's answer)

If your schema rarely changes it might make sense to have a completely separate build which just creates the JAXB generated code, jars it, versions it, and sticks it in your repository.

Then in your downstream code you use that jar as a dependency and subclass the JAXB code as necessary to add your new fields.

We went this route because we felt that having JAXB complile every time we did a build was unnecessary as our schemas were pretty static.

Most importantly: forget about modifying the generated sources; why introduce an error prone manual step in your development process when you can get the same effect automatically?

Absolutely.

To elaborate and extend on a point already well-made... if there are a lot of implicit relationships and things you'd like to put "getters" on the JAXB code for, bite the bullet and wrap the JAXB class hierarchy in one that does exactly what you want where you want it.

With IDE-assisted delegation, this is only a little tedious, and factors a lot of straightforward, distracting, low-level code out of your main app.

Another benefit of this is that you'll spend a lot less time fighting JAXB to generate things exactly the way you want - the wrappers will make you care a whole lot less.