别再望了！ 关于“将生成的代码放在哪里的最终答案”

最近关于Stack Overflow的问题使我思考 。

jOOQ为什么建议将生成的代码放在“ / target”下而不是“ / src”下？

……而我将为您提供“对将生成的代码放置在何处？”的最终答案。

这不仅与jOOQ有关

即使您没有使用jOOQ ，或者即使您正在使用jOOQ但没有代码生成器 ，项目中也可能会生成一些源代码。 有许多工具可以从其他数据生成源代码，例如：

• Java编译器（好的，字节码，不是严格的源代码。但是仍然是代码生成）
• XJC ，来自XSD文件
• 从.hbm.xml文件或您的架构中休眠
• Xtend将Xtend代码转换为Java代码
• 您甚至可以考虑进行数据转换，例如XSLT
• 还有很多…

在本文中，我们将研究如何处理jOOQ生成的代码，但是相同的想法也适用于从其他代码或数据生成的任何其他类型的代码。

现在，我们需要问自己一个非常非常有趣的战略问题 ：将代码放在哪里？ 在版本控制下，像原始数据一样？ 还是我们应该将生成的代码视为必须一直重新生成的派生代码？

答案在附近…

这取决于！

不幸的是，不像其他许多无聊的讨论一样 ，这个回答也没有完全正确或错误的答案。 本质上有两种方法：

将生成的代码视为代码库的一部分

当您考虑将生成的代码作为代码库的一部分时，您将需要：

• 在版本控制系统中签入生成的源
• 使用手动源代码生成
• 甚至可以使用部分源代码生成

当您的Java开发人员无法完全控制数据库模式（或XSD或Java代码等）或无法完全控制您的数据库模式时，或者如果您有许多同时使用同一模块的开发人员时，这种方法特别有用。数据库模式，该模式一直在变化。 跟踪数据库更改的副作用也很有用，因为当您要分析架构的历史记录时可以考虑签入的数据库架构。

使用这种方法，您还可以跟踪jOOQ代码生成器中行为的变化，例如在升级jOOQ或修改代码生成配置时。

使用这种方法时，会将生成的代码视为具有自己生命周期的外部库。

这种方法的缺点是它更容易出错，并且可能会因为实际模式可能与生成的模式不同步而增加工作量。

将生成的代码视为派生产品

当您认为生成的代码是人工制品时，您将需要：

• 仅签入实际的DDL，即“真相的原始来源” （例如，通过Flyway进行控制）
• 每次模式更改时都重新生成jOOQ代码
• 在每台机器上重新生成jOOQ代码-包括连续集成机器，如果可能的话，也可能在生产中

当您有一个较小的数据库架构，该架构由Java开发人员完全控制时，这种方法特别有用。Java开发人员希望从能够在构建的每个步骤中重新生成所有衍生工件的更高质量中受益。

例如，Maven完全支持此方法，它预见了专门用于源代码生成的特殊目录（例如target/generated-sources ）和阶段（例如<phase>generate-sources</phase> ）。

这种方法的缺点是，当数据库的某些部分暂时不可用时，构建可能会在完全“可接受”的情况下中断。

务实的方法

你们中的某些人可能不喜欢这个答案，但是也有一种务实的方法，两者结合。 您可以将某些代码视为代码库的一部分，并将某些代码视为派生的代码 。 例如，jOOQ-meta的生成源（用于在生成jOOQ代码时查询字典视图/ INFORMATION_SCHEMA）受版本控制，因为很少有jOOQ贡献者能够对所有受支持的数据库运行jOOQ-meta代码生成器。 但是在许多集成测试中，我们每次都会重新生成源代码，以确保代码生成器正常工作。

！

结论

很抱歉使您失望。 对于一种方法还是另一种方法是否更好没有最终的答案。 选择一种可以在您的特定情况下为您提供更多价值的产品。

如果您选择将生成的代码作为代码库的一部分，请阅读Witold Szczerba关于jOOQ用户组的这份有趣的体验报告，以了解如何最好地实现这一目标。

翻译自: https://www.javacodegeeks.com/2014/09/look-no-further-the-final-answer-to-where-to-put-generated-code.html