将大型模式编译成Java

有两个主要工具提供了将XSD模式编译成Java的方法：xmlbeans和JAXB

问题是XSD模式非常庞大：30MB的XML文件，大多数模式没有在我的项目中使用，因此我可以注释掉大部分代码，但这不是一个好的解决方案

目前，我的项目使用xmlbeans，它编译带有重大更改的模式。它产生约60MB的类，编译大约需要30分钟

另一个解决方案是使用JAXB，它可以生成约14MB的代码，而无需编辑代码。但它会产生巨大的ObjectFactory类，该类无法编译，并出现“常量太多”错误。我可以扔掉这个类，编译没有它的模式，但据我所知，它是一个非常有用的类

---

有没有办法处理这个庞大的模式？

在使用XmlBeans或JAXB进行映射之前，您能否创建一个脚本来提取您需要的模式部分并将其集成到构建过程中

您可能可以用Python、Perl、Awk等相当简单和容易地编写这个提取脚本；如果你有XSL方面的专业知识，甚至可以使用XSL（我从来没有花足够的时间连续编写XSL，所以我可能会坚持使用脚本语言，但这只是我自己）

e、 g:

python extract.py big-schema.xsd>small-schema.xsd
xsd2java小型模式.xsd
...

您可能会发现，第三方供应商的后续更新会使提取脚本无效，但除非他们对整个架构进行非常大的更改，否则您应该能够相当快地更新脚本，而且这些更新听起来应该相当不频繁

---

顺便说一句，我有点偏爱XmlBeans；当我们自己评估XMLJava映射工具时，它似乎比我们尝试的任何其他方法都能更好地处理诸如xs:choice、xs:all和类型替换之类的构造。但那是几年前的事了，现在肯定已经改变了。在这一点上，我们继续使用它更多的是出于制度惯性而不是其他原因，所以对这一建议稍加保留。

30Mb的模式？这到底是什么？我想知道它是否可以作为模式处理器的测试用例

---

数据映射（alajaxb）最适合于小型模式。我见过当模式变得大约200个元素类型时，人们真的很挣扎。你一定是在处理一些更大几个数量级的事情——我会说这是一个非起点

根本不使用模式，而是通过流式处理文档来挑选您需要的内容。我建议您使用这种b/c模式，您可以说您只使用了一小部分XML模式。我们使用了模式的一小部分，但这一部分太大，无法自行实现。此外，3d第三方供应商每年都会更新此模式，因此它用于检查与新API的兼容性。很难跟踪对SchemaAllRight的所有更改，我想我不知道您想要什么。您是在读还是在写这个XML，还是两者都读？模式多久更改一次？您想用XML完成什么任务？您不需要使用XSD来制作供应商可以接受的文档，您可以用任何旧方法制作文档，只要它们正确无误。您可以将XSD验证合并到您的测试套件中，但可以将文档作为标记汤进行操作。使用XSD模式描述服务协议。因此，我们有一个与该服务对话的应用程序，它利用xmlbeans生成的类。我的任务是重构此应用程序，以使用此协议的不同版本，并避免修改原始模式。我很好奇供应商如何处理xsd。是的，此模式来自一家大型IT公司，所以没关系：）JAXB将此模式快速编译成小包。唯一的问题是生成的ObjectFactory类的大小，它不会编译。我试图破解javac（增加了常量数量的限制），然后它编译得很好，但是没有破解，java本身无法识别这个类，所以这个破解是没有用的。如果有办法分割这个文件。。。但我不知道如何实现自动化：（最近，我使用diff/patch实现了修改的自动化，但后来我手动修复了冲突。我还想将项目重构为JAXB，因为它非常现代、原生和轻量级。但无论如何，这是一个解决方案，但不是一个很好的解决方案。

python extract.py big-schema.xsd >small-schema.xsd
xsd2java <args> small-schema.xsd
...