放置自动生成代码的好地方？
我们有一堆自动生成的类，主要是 Axis2 存根、骨架等。对于一些复杂的 wsdls，Axis2 生成大量 java-bean、存根等。我确信在使用自动生成时还有其他情况。
现在，我们将它们视为代码库的其他一流成员，并将它们存储在相同的包中。
然而，在进行重构、清理等时，很难清除来自这些自动生成的类的警告。 例如，如果我尝试清理代码以便使用 Java1.5 泛型，则没有好方法可以知道这些违规类中有多少是我们的，还是自动生成的。
我应该将这些自动生成的部分分离到不同的包中吗？ 你们如何在存储库中存储这些工件？
编辑： 我在下面的很多答案中看到“在构建过程中生成”。 虽然我看到了这样做的好处，但我不太明白如何摆脱存储库签入。
我的代码对其中一些类有编译时依赖性，对我来说，开发期间的构建是 Eclipse 中的“ctrl-s”。 我们使用 ant 脚本来生成编译、运行测试并生成可交付成果。
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.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
最佳实践总结：
Summary of best practices:
您可以保留相同的包，但使用不同的源文件夹（例如 generated-src），这就是我们所做的。 实际上，我对将生成的代码保存在源代码存储库中的整个想法持观望态度。 我们这样做是为了方便项目中的其他开发人员，但作为构建过程的一部分重新生成源代码通常是有意义的。 如果生成的代码不太可能更改，那么使用单独的项目并生成 jar 可能更实用。
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.
我将这些文件放入自己的项目中。 这样，我可以在一个位置添加构建文件、我需要的所有补丁等，并关闭生成代码的所有警告。
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.
如果您要将它们签入源代码控制系统，请不要这样做。 让它们通过构建步骤重新生成。 如果它们是从 WSDL 生成的，请签入 WSDL，而不是结果代码。
我建议让该构建步骤为生成的代码生成一个完全独立的 .jar，然后删除源文件，只是为了尽可能避免维护人员尝试手动编辑自动生成的源代码。
这样，您的重构活动就会将自动生成的代码视为第三方库，而不是要操作的源代码。
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.
对于每组生成的工件，创建一个执行生成的新项目，然后将工件捆绑到 JAR 和源 ZIP 文件中，然后从您的应用程序中引用它们。 保持事物的美好和独立，并强调生成的工件不能由 IDE 更改这一事实。
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.
使用 maven 和 axistools-maven-plugin，生成的源位于“目标”目录中的不同源文件夹中。 这个目标目录是maven生成所有文件和东西的地方，所以它可以被清理。
这非常方便，因为生成的文件也会出现在 IDE 内的不同源文件夹中。
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.