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

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)