请在2024年Clojure调查问卷!中分享您的想法。

欢迎!请在关于页面了解更多关于这个网站如何运作的信息。

+1
tools.build
重新分类

为了在Java生态系统中正常运行,可以在pom.xml文件中包含范围设置为'provided'的库的可选依赖项。

deps.edn明确不支持包含范围设置为'provided'的依赖项,而是使用别名。

为了在有更广泛的Java生态系统中作为一个库正常工作,能够输出一个包含额外依赖项的pom.xml文件的库jar文件将非常有帮助,这些依赖项不在deps.edn中,但范围为'provided'供Java构建工具使用。

例如,cljdoc在构建库时会因为没有包括适当的依赖项而无法构建文档。

'write-pom'已提供包含模板'源'pom.xml的选项,但依赖项会被deps.edn文件的信息覆盖。

有解决方案——例如,请参阅https://clojurians.slack.com/archives/C8V0BQ0M6/p1680090647156119中的线程,该线程通过包含范围设置为'provided'的依赖项来修改过程——但它们并不理想。

选项。

  1. 不采取行动——根据Slack线程的示例对tools.build进行monkey补丁,或者修改生成的pom.xml以包含额外的范围设置为'provided'的依赖项。

  2. 从源(模板)pom.xml合并现有的依赖项而不是覆盖[但这可能是破坏性更改]

  3. 为'write-pom'提供附加参数以包含任意依赖项,这是一个包含范围映射(这些可选依赖项的范围将为:provided)的映射的序列。

  4. 与cljdoc协作,以支持别名,这样文档构建就可以由库作者自定义,从而避免此类构建失败。

1 个答案

+2
第一印象是我会倾向于第3个选项。
按照第3个选项,能否形成类似于`:pom-plugins` Leiningen等价物,能生成`<plugins><plugin>...</plugin></plugins>`块?

是否有更好的方法添加自定义的maven块?一些maven插件也可以添加新元素和属性。
对于:dependencies、:repositories以及我们设定的其它少量内容以外的其它部分,最好将这些信息放在template pom.xml模板中。
...