处理 当一个项目依赖于具有闭源的许可证的jar,该许可证阻止其存在中央存储库中 的情况----三种方法
2018-03-28 15:31
477 查看
三种方法处理当一个项目依赖于具有闭源的许可证的jar,该许可证阻止其存在中央存储库中 的情况
1、使用install插件在本地安装依赖项。该方法是最简单的推荐方法。mvn install:install-file -Dfile=non-maven-proj.jar -DgroupId=some.group -DartifactId=non-maven-proj -Dversion=1 -Dpackaging=jar注意:地址仍然是必需的,只有在你使用命令行时,安装插件才会使用给定地址为你创建POM。
2、创建自己的存储库并将其部署到那里。对于使用内联网的公司来说,这是一个最喜欢的方法,并且需要能够保持每个人的同步。有一个名为deploy的Maven目标:deploy-file与install:install-file目标类似。
3、将依赖范围设置为system并定义一个systemPath。但是,这并不推荐,但是可以让我们解释以下内容:
classifier (分类器): 允许区分使用相同POM构建但内容不同的工件。它是一些可选的和任意的字符串,如果存在的话,会附加到版本号后面的工件名称。作为这个元素的动机,考虑一个项目,该项目提供了一个针对JRE 1.5的工件,但同时也是一个仍然支持JRE 1.4的工件。第一个artifact可以装备 classifier jdk15,第二个artifact 有jdk14,这样客户可以选择使用哪一个。classifier 的另一个常见用例是需要将辅助工件附加到项目的主要artifact上。如果你浏览Maven中央存储库,你会注意到使用了classifiers 的源代码和javadoc来将项目源代码和API文档与打包的类文件一起部署。
type (类型):对应于相关工件的packaging 类型。这默认为jar。虽然它通常表示依赖项文件名的扩展名,但并非总是如此。一个类型可以映射到不同的扩展和classifier。该类型通常对应于所使用的packaging ,但这并非总是如此。一些例子是jar,ejb-client和test-jar。新类型可以通过将extensions 设置为true 的插件来定义,所以这不是一个完整的列表。
scope : 该元素引用了手头任务的类路径(编译和运行时,测试等),以及如何限制依赖关系的传递性。有五个范围可用:
compile : 这是默认范围,如果没有指定,则使用该范围。compile 依赖关系在所有类路径中都可用。而且,这些依赖关系 会传播到依赖项目。
provided : 这非常类似于编译,但表示您期望JDK或容器在运行时提供它。它仅在编译和测试类路径中可用,并且不是传递性 的。
runtime:此范围指示编译时不需要依赖关系,但用于执行。它在运行时和测试类路径中,但不在编译类路径中。
test:此范围指示正常使用应用程序时不需要依赖关系,并且仅适用于测试编译和执行阶段。它不是传递性的。
system :这个范围与provided 范围相似,除了你必须明确地提供包含它的JAR。工件始终可用,并且不会在存储库中查找。
systemPath :用于仅当所述依赖关系scope 是 system 。否则,如果设置此元素,构建将失败。路径必须是绝对路径,因此建议使用属性来指定机器特定路径。由于假定系统范围依赖关系是事先安装的,因此Maven不会检查项目的存储库,而是检查以确保文件存在。如果没有,Maven将会失败,并建议您手动下载并安装它。
optional : 当项目本身是一个依赖项时,标记可选的依赖项。例如,设想一个项目A依赖于项目B来编译一部分代码,这些代码在运行时可能不会被使用,那么我们可能不需要为所有项目使用项目B. 因此,如果项目X添加项目A作为自己的依赖,那么Maven将完全不需要安装项目B。象征性地,如果=>表示一个必须的依赖,-- >表示可选的依赖,尽管当构建项目A的时候,也许是A =>B这种情况,但是当构建项目X的时候也许就是X => A -->B这种情况了。【这段是翻译后的文字,可能有些不妥,以下为未翻译的内容:Marks optional a dependency when this project itself is a dependency. Confused? For example, imagine a project A that depends upon project B to compile a portion of code that may not be used at runtime, then we may have no need for project B for all project. So if project X adds project A as its own dependency, then Maven will not need to install project B at all. Symbolically, if => represents a required dependency, and --> represents optional, although A=>B may be the case when building A X=>A-->B would be the case when building X.】 在最短的时间内,optional 可以让其他项目知道,当你使用这个项目时,为了正常工作,你不需要这个依赖项。
1、使用install插件在本地安装依赖项。该方法是最简单的推荐方法。mvn install:install-file -Dfile=non-maven-proj.jar -DgroupId=some.group -DartifactId=non-maven-proj -Dversion=1 -Dpackaging=jar注意:地址仍然是必需的,只有在你使用命令行时,安装插件才会使用给定地址为你创建POM。
2、创建自己的存储库并将其部署到那里。对于使用内联网的公司来说,这是一个最喜欢的方法,并且需要能够保持每个人的同步。有一个名为deploy的Maven目标:deploy-file与install:install-file目标类似。
3、将依赖范围设置为system并定义一个systemPath。但是,这并不推荐,但是可以让我们解释以下内容:
classifier (分类器): 允许区分使用相同POM构建但内容不同的工件。它是一些可选的和任意的字符串,如果存在的话,会附加到版本号后面的工件名称。作为这个元素的动机,考虑一个项目,该项目提供了一个针对JRE 1.5的工件,但同时也是一个仍然支持JRE 1.4的工件。第一个artifact可以装备 classifier jdk15,第二个artifact 有jdk14,这样客户可以选择使用哪一个。classifier 的另一个常见用例是需要将辅助工件附加到项目的主要artifact上。如果你浏览Maven中央存储库,你会注意到使用了classifiers 的源代码和javadoc来将项目源代码和API文档与打包的类文件一起部署。
type (类型):对应于相关工件的packaging 类型。这默认为jar。虽然它通常表示依赖项文件名的扩展名,但并非总是如此。一个类型可以映射到不同的扩展和classifier。该类型通常对应于所使用的packaging ,但这并非总是如此。一些例子是jar,ejb-client和test-jar。新类型可以通过将extensions 设置为true 的插件来定义,所以这不是一个完整的列表。
scope : 该元素引用了手头任务的类路径(编译和运行时,测试等),以及如何限制依赖关系的传递性。有五个范围可用:
compile : 这是默认范围,如果没有指定,则使用该范围。compile 依赖关系在所有类路径中都可用。而且,这些依赖关系 会传播到依赖项目。
provided : 这非常类似于编译,但表示您期望JDK或容器在运行时提供它。它仅在编译和测试类路径中可用,并且不是传递性 的。
runtime:此范围指示编译时不需要依赖关系,但用于执行。它在运行时和测试类路径中,但不在编译类路径中。
test:此范围指示正常使用应用程序时不需要依赖关系,并且仅适用于测试编译和执行阶段。它不是传递性的。
system :这个范围与provided 范围相似,除了你必须明确地提供包含它的JAR。工件始终可用,并且不会在存储库中查找。
systemPath :用于仅当所述依赖关系scope 是 system 。否则,如果设置此元素,构建将失败。路径必须是绝对路径,因此建议使用属性来指定机器特定路径。由于假定系统范围依赖关系是事先安装的,因此Maven不会检查项目的存储库,而是检查以确保文件存在。如果没有,Maven将会失败,并建议您手动下载并安装它。
optional : 当项目本身是一个依赖项时,标记可选的依赖项。例如,设想一个项目A依赖于项目B来编译一部分代码,这些代码在运行时可能不会被使用,那么我们可能不需要为所有项目使用项目B. 因此,如果项目X添加项目A作为自己的依赖,那么Maven将完全不需要安装项目B。象征性地,如果=>表示一个必须的依赖,-- >表示可选的依赖,尽管当构建项目A的时候,也许是A =>B这种情况,但是当构建项目X的时候也许就是X => A -->B这种情况了。【这段是翻译后的文字,可能有些不妥,以下为未翻译的内容:Marks optional a dependency when this project itself is a dependency. Confused? For example, imagine a project A that depends upon project B to compile a portion of code that may not be used at runtime, then we may have no need for project B for all project. So if project X adds project A as its own dependency, then Maven will not need to install project B at all. Symbolically, if => represents a required dependency, and --> represents optional, although A=>B may be the case when building A X=>A-->B would be the case when building X.】 在最短的时间内,optional 可以让其他项目知道,当你使用这个项目时,为了正常工作,你不需要这个依赖项。
相关文章推荐
- maven项目,多个依赖,打成一个可执行jar包,可根据profiles进行打包,出现的Could not find or load main class的解决方法。
- maven下载依赖jar包失败的一个很笨的处理方法
- html与嵌入其中的flash均存在滚动条的情况分析及处理方法
- SQL Server在存储过程中编写事务处理代码的三种方法
- SQL Server在存储过程中编写事务处理代码的三种方法
- 3.将maven项目jar纳入maven仓库,Mave项目依赖另外一个Maven项目的案例
- Struts2中一个Action多个请求处理方法的三种实现方式
- Struts2中一个Action多个请求处理方法的三种实现方式
- Jquery的validate,清除form方法,显示密插件,正则特殊字符处理,js的call用法,ajax,h5支持情况,elclipse tomcate去掉项目名,js 的原型
- 【Qt】窗体间传递数据(跨控件跨类),三种情况与处理方法
- python实现每次处理一个字符的三种方法
- maven依赖本地非repository中的jar包-依赖jar包放在WEB-INF/lib等目录下的情况客户端编译出错的处理
- SQL Server在存储过程中编写事务处理代码的三种方法
- C++开发中一个解决方案里,两个项目的相互引用,相互依赖的实现方法(解决方法)
- 【C语言】要求找出具有下列性质的数的个数(包含输入的自然数n): 先输入一个自然数n(n<=500),然后对此自然数按照如下方法进行处理:
- 使用反射令2个事件在不知道方法名的情况下使用同一个处理方法
- 把项目运行情况写入系统日志(Log)的三种方法【续】_AX
- 关于MFC控件删除出现“具有该ID的控件已存在”这样的情况的解决方案,详细,网上都没有这么详细的,我是“深受其害”,所以想将详细的方法分享出去。
- SQL Server在存储过程中编写事务处理代码的三种方法
- SQL Server在存储过程中编写事务处理代码的三种方法