A good place to put autogenerated code?

Question

We have bunch of autogenerated classes which are mostly Axis2 stubs, skeletons etc. For some complicated wsdls, Axis2 generates a TON of java-beans, stubs etc. And I am sure there are other cases too when auto generation is used.

For now we treat these as other first class members of our code-base and they are stored in the same packages.

However when doing refactoring, cleanups etc it becomes hard to weed out the warnings that are coming from these auto-generated classes. For example, if I am trying to clean up the code so as to use Java1.5 generics, there is no good way to know how many of these offending classes are ours vs being auto-generated.

Should I be separating these autogenerated parts out into a different package? How do you guys store such artifacts in the repository?

EDIT: I see 'generate during build process' in quite a few answers below. While I see the benefits of doing that, I dont quite see how I can get away from a repository checkin.

My code has compile time dependencies on some of these classes and for me, a build during development is a 'ctrl-s' in eclipse. We use ant-scripts to generate the compile, run tests and generate deliverables.

Answer 1

I put these files into a project of their own. This way, I can add the build file, all the patches I need, etc. in a single place and turn off all warnings for the generated code.

Answer 2

For each set of generated artifacts, create a new project which performs the generation, then bundles the artifacts up into JAR and source ZIP files, and then reference them from your app. Keeps things nice and seperate, and emphasises the fact that the generated artifacts are not for changing by the IDE.

Answer 3

If you're checking them into your source control system, don't. Make them get re-generated by a build step. If they get generated from a WSDL, check in the WSDL, not the resulting code.

I'd recommend having that build step generate a completely separate .jar for the generated code, and then deleting the source files, just to make it as unlikely as possible that maintainers will try to hand edit the auto-generated source.

That way, your refactoring activities will see the autogenerated code as like a third-party library instead of source to be manipulated.

Answer 4

You can keep the same packages but use a different source folder (something like generated-src), which is what we do. I'm actually on the fence about the whole idea of saving generated code in the source code repository. We do it as a convenience for other developers on the project, but it usually makes sense to regenerate the source code as part of the build process. If this generated code is unlikely to change, then using a separate project and generating a jar might be more practical.

Answer 5

with maven and axistools-maven-plugin, the generated sources are places in a different source folder in the 'target' directory. this target directory is where maven generates all files and stuff, so it can be cleaned.
This is very conviniened, because the generated files also appears in a different source folder within the IDE.

Answer 6

Summary of best practices:

• Make it repeatable
  • Create generated code as part of a build process.
  • Don't check generated code into source control. (Do check in the source. e.g. WSDL)
• Keep generated code separate from managed code
  • Use a different source folder for generated output.
  • Deliver a separate .jar so that this generated code becomes a dependency.
  • Consider using a different IDE project (or maven module)