The practical problem with both these approaches that very few Maven Central modules have up-to-date license information in their POMs. So from what I can see this is a great idea which falls short of a real solution to the problem of assessing your build's license compliance...
My ideal solution is an external set of processes which scan the contents of the Nexus repository for available license information. This information is then used to seed the Nexus Professional's procurement suite to control the contents of an approved repository for use in release (non development builds).
Some binaries contain textual license files and alternatively the associated source code packages could be also be scanned for license and IP information. A number of 3rd party tools are available to perform this task. The ones I've been considering are:
In conclusion, until Maven Central can provide reliable meta data on module licensing, I think solutions to this problem will remain highly customised and sub-optimal
The approach taken by Artifactory is a bit different, since raw artifact metadata is only used as starting point, but at the end of the day users can complete and amend missing/incorrect license information:
At first, POM (including all parent POMs) or Ivy descriptors are used to extract heuristic license information. This auto-discovery step is purely optional.
This license information is then attached to artifacts based on their checksum, and is fully editable by users. Admins can update the license details which will stick with the artifact for its lifetime.
Every license can be approved or unapproved according to a global policy.
At deployment time the license info of all dependencies is read - if unapproved or unknown licenses are found an email alert with the information is sent to preconfigured addresses.
This lets you deal with changes/additions of new dependencies (and their respective licenses) as soon as they are committed and picked-up by the build process.
Another key difference is the ability to handle artifacts with multiple-licenses, where only one of the licenses is approved and the others are not.
A customized solution for use with Artifactory + Ivy + ant is to scan each module for license information. If the license is found, populate that license file in Artifactory and update it's ivy.xml to have it available as a published artifact. Then call <ivy:retrieve/> to fetch the license along with its jar file.
The license can be specified within the module's ivy.xml as a URL. In this case, use ant's get task to download the license and write it to a text file.
[inside log4j's ivy.xml as an example]
<ivy-module xmlns:m="http://ant.apache.org/ivy/maven" version="2.0">
<info organisation="log4j" module="log4j" revision="1.2.16" status="integration"
publication="20120620150430">
<license name="The Apache Software License, Version 2.0"
url="http://www.apache.org/licenses/LICENSE-2.0.txt"/>
...
</info>
</ivy-module>
Alternatively, the license can be included as a text file within the module's .jar file. In this case, use ant's unjar task to extract the license and write it to a text file.
[inside junit's .jar file as an example]
junit-4.8.2.jar/LICENSE.txt
Once the license has been written out as a text file, use ant's xmltask task to add the license as an artifact.
[inside log4j's ivy.xml as an example]
<publications>
<artifact conf="master" ext="jar" name="log4j" type="bundle"/>
<artifact conf="sources" ext="jar" m:classifier="sources" name="log4j" type="source"/>
<artifact conf="javadoc" ext="jar" m:classifier="javadoc" name="log4j" type="javadoc"/>
<!-- next line added -->
<artifact conf="master" ext="txt" name="log4j" type="license"/>
</publications>
Publish the modified ivy.xml and the license back to Artifactory.
发布评论
评论（3）
可以使用 Maven 许可证验证器插件 http://code 来模拟 Artifactory 功能
。 google.com/p/maven-license-validator-plugin/
这两种方法的实际问题是很少有 Maven Central 模块在其 POM 中具有最新的许可证信息。因此，从我看来，这是一个好主意，但它不足以真正解决评估构建的许可证合规性问题...
我理想的解决方案是一组外部进程，用于扫描 Nexus 存储库的内容以获取可用许可证信息。然后，此信息将用于为 Nexus Professional 的采购套件提供种子，以控制已批准的存储库的内容以供发布（非开发版本）使用。
一些二进制文件包含文本许可证文件，或者也可以扫描关联的源代码包以获取许可证和 IP 信息。许多第三方工具可用于执行此任务。我一直在考虑的是：
总之，在 Maven Central 能够提供有关模块许可的可靠元数据之前，我认为这个问题的解决方案将仍然是高度定制的和次优的
The Artifactory functionality can be emulated using the Maven license validator plugin
http://code.google.com/p/maven-license-validator-plugin/
The practical problem with both these approaches that very few Maven Central modules have up-to-date license information in their POMs. So from what I can see this is a great idea which falls short of a real solution to the problem of assessing your build's license compliance...
My ideal solution is an external set of processes which scan the contents of the Nexus repository for available license information. This information is then used to seed the Nexus Professional's procurement suite to control the contents of an approved repository for use in release (non development builds).
Some binaries contain textual license files and alternatively the associated source code packages could be also be scanned for license and IP information. A number of 3rd party tools are available to perform this task. The ones I've been considering are:
In conclusion, until Maven Central can provide reliable meta data on module licensing, I think solutions to this problem will remain highly customised and sub-optimal
Artifactory 采取的方法有点不同，因为原始工件元数据仅用作起点，但最终用户可以完成并修改丢失/不正确的许可证信息：
这使您可以在构建过程提交并获取新依赖项（及其各自的许可证）后立即处理它们的更改/添加。
另一个关键区别是处理具有多个许可证的工件的能力，其中只有一个许可证获得批准，而其他许可证则没有。
您可以在这里阅读更多相关信息 -
http://wiki.jfrog.org/confluence /显示/RTF/许可证+控制
The approach taken by Artifactory is a bit different, since raw artifact metadata is only used as starting point, but at the end of the day users can complete and amend missing/incorrect license information:
This lets you deal with changes/additions of new dependencies (and their respective licenses) as soon as they are committed and picked-up by the build process.
Another key difference is the ability to handle artifacts with multiple-licenses, where only one of the licenses is approved and the others are not.
You can read more about it here -
http://wiki.jfrog.org/confluence/display/RTF/License+Control
与 Artifactory + Ivy +
ant结合使用的定制解决方案是扫描每个模块以获取许可证信息。如果找到许可证，请在 Artifactory 中填充该许可证文件并更新其ivy.xml以将其作为已发布的工件提供。然后调用许可证可以在模块的
ivy.xml中指定为 URL。在这种情况下，请使用ant的get任务下载许可证并将其写入文本文件。或者，许可证可以作为文本文件包含在模块的
.jar文件中。在这种情况下，请使用ant的unjar任务提取许可证并将其写入文本文件。将许可证写成文本文件后，请使用
ant的 xmltask 任务，将许可证添加为工件。将修改后的
ivy.xml和许可证发布回 Artifactory。与您的构建捆绑时，使用
A customized solution for use with Artifactory + Ivy +
antis to scan each module for license information. If the license is found, populate that license file in Artifactory and update it'sivy.xmlto have it available as a published artifact. Then call<ivy:retrieve/>to fetch the license along with its jar file.The license can be specified within the module's
ivy.xmlas a URL. In this case, useant'sgettask to download the license and write it to a text file.Alternatively, the license can be included as a text file within the module's
.jarfile. In this case, useant'sunjartask to extract the license and write it to a text file.Once the license has been written out as a text file, use
ant's xmltask task to add the license as an artifact.Publish the modified
ivy.xmland the license back to Artifactory.Use
<ivy:retrieve/>to fetch the license along with its jar file when bundling with your build.