Tag: xerces

在Java / Maven中处理“Xerces hell”？

在我的办公室里，仅仅提到Xerces这个词就足以激起开发者的愤怒。 粗略地看一下其他Xerces上的SO问题似乎表明，几乎所有的Maven用户都被这个问题“触动”了一些。 不幸的是，理解这个问题需要对Xerces的历史有一些了解。 历史 Xerces是Java生态系统中使用最广泛的XMLparsing器。 几乎每个使用Java编写的库或框架都以某种身份使用Xerces（即使不是直接传递）。 包括在官方二进制文件中的Xercesjar子至今还没有版本。 例如，Xerces 2.11.0实现jar被命名为xercesImpl.jar而不是xercesImpl-2.11.0.jar 。 Xerces团队不使用Maven ，这意味着他们不会将正式版本上传到Maven Central 。 Xerces曾经作为一个单独的jar （ xerces.jar ）被释放 ，但被分成了两个jar，一个包含API（ xml-apis.jar ），另一个包含这些API（ xml-apis.jar ）的实现。 许多较老的Maven POM仍然声明对xerces.jar的依赖。 在过去的某个时候，Xerces也是以xmlParserAPIs.jar发布的，一些较老的POM也依赖它。 那些将他们的jar部署到Maven仓库的人分配给xml-apis和xercesImpl jar的版本通常是不同的。 例如，xml-apis可能会被赋予1.3.03版本，而xercesImpl可能会被赋予2.8.0版本，即使两者都来自Xerces 2.8.0。 这是因为人们经常使用它实现的规范版本来标记xml-apis jar。 这里有一个非常好的，但不完整的细分。 更为复杂的是，Xerces是JRE中包含的用于XML处理的Java API的参考实现（JAXP）中使用的XMLparsing器。 实现类在com.sun.*命名空间下重新打包，这使得直接访问这些实现类非常危险，因为它们可能在某些JRE中不可用。 但是，并非所有的Xercesfunction都通过java.*和javax.* API公开; 例如，没有暴露Xerces序列化的API。 除此之外，几乎所有的servlet容器（JBoss，Jetty，Glassfish，Tomcat等）都在Xerces的一个或多个/lib文件夹中提供。 问题 解决冲突 对于上面的一些原因或者全部原因，许多组织在他们的POM中发布和使用Xerces的自定义版本。 如果你有一个小应用程序并且只使用Maven Central，那么这不是一个真正的问题，但是它很快就会成为Artifactory或者Nexus代理多个仓库（JBoss，Hibernate等）的企业软件的一个问题： 例如，组织A可能会将xml-apis发布为： <groupId>org.apache.xerces</groupId> <artifactId>xml-apis</artifactId> <version>2.9.1</version> 同时，组织B可能会发布相同的jar： <groupId>xml-apis</groupId> <artifactId>xml-apis</artifactId> <version>1.3.04</version> 尽pipeB的jar比A的jar版本更低，但Maven并不知道它们是相同的，因为它们具有不同的groupId 。 […]