Let's say that you have a project which is using a 3rd party library, such as Google's Analytics Data API (gdata), which does not appear to be currently deployed into any well-known or popular Maven public repositories/indexes. This isn't much of a problem, as I can just deploy the artifact into my local hosted Nexus repository.
假设您有一个使用第三方库的项目,例如Google的Analytics Data API(gdata),它似乎当前未部署到任何知名或流行的Maven公共存储库/索引中。这不是什么大问题,因为我可以将工件部署到我的本地托管的Nexus存储库中。
But, are there any best practices in the Maven community for how I should name this library's "coordinates" in my POM, since a standard is not already set in public repositories for it?
但是,Maven社区中有没有关于如何在我的POM中命名这个库的“坐标”的最佳实践,因为标准尚未在公共存储库中设置呢?
For example, should I refer to it in my POM as
例如,我应该在我的POM中引用它
<dependency>
<groupId>com.google</groupId>
<artifactId>gdata-analytics</artifactId>
<version>1.0</version>
</dependency>
or is there some better / more standard way for me to come up with the artifactId?
还是有一些更好/更标准的方法让我想出artifactId?
(And, why the heck wouldn't a provider of a few dozen libraries such as Google take some effort to get them hosted into the mainstream public Maven repositories/indexes? Wouldn't this make it easier for people to use them and thus drive up adoption?)
(而且,为什么像谷歌这样的几十家图书馆的提供商不会花费一些精力将它们托管到主流的公共Maven存储库/索引中?这不会让人们更容易使用它们从而驱动它们收养?)
5 个解决方案
#1
What you've done is pretty reasonable. A few extra points:
你做的很合理。一些额外的要点:
-
When Maven obtains an artifact from Nexus, the artifact is named as artifactId-version. GroupId is annoyingly omitted. So, when the artifact is moved around (say, copied into WEB-INF/lib in a web app), your jar file will read "gdata-analytics-1.0". That's usually not a problem. However, if the artifact name is very common, like "util", you may want to include group information inside the artifactId, such as using groupId of "com.google" and an artifactId of "com.google.gdata-analytics". Yes, the repitition is annoying, but it yields maximum clarity on the file system and in searches. I've actually had a problem where two different groupIds both had a "core-1.0" jar, and one overwrote the other when being copied into the lib directory at build time.
当Maven从Nexus获取工件时,该工件被命名为artifactId-version。 GroupId被省略了。因此,当工件移动(例如,复制到Web应用程序中的WEB-INF / lib)时,您的jar文件将显示为“gdata-analytics-1.0”。这通常不是问题。但是,如果工件名称非常常见,例如“util”,您可能希望在artifactId中包含组信息,例如使用“com.google”的groupId和“com.google.gdata-analytics”的artifactId。是的,重复是令人讨厌的,但它会在文件系统和搜索中产生最大的清晰度。我实际上有一个问题,其中两个不同的groupId都有一个“core-1.0”jar,一个在构建时被复制到lib目录时覆盖了另一个。
-
I second MattK's suggestion of aligning your Maven versionId with whatever version the artifact is commonly known by.
我的第二个MattK建议将你的Maven versionId与通常所知的工件版本对齐。
-
If you follow Dominic's advice of prefixing the groupId with your own company name (eg acme), it may make it easier to take advantage of Nexus' routing feature. It will ensure that requests for internal artifacts aren't propagated out to Maven Central and end up in their logs (which may be important if your groupId is "acme.secret.project"!
如果您遵循Dominic的建议,将groupId添加前缀为您自己的公司名称(例如acme),则可以更轻松地利用Nexus的路由功能。它将确保内部工件的请求不会传播到Maven Central并最终存储在他们的日志中(如果您的groupId是“acme.secret.project”,这可能很重要!
#2
I've been using Maven for about a year and have never run across a "standard" naming convention. I usually do exactly what you're doing, although I try to make the version number as close to the "real" version number as possible, just to avoid confusion in case I deploy multiple versions.
我已经使用Maven大约一年了,并且从未遇到过“标准”命名约定。我通常会做你正在做的事情,虽然我尽量使版本号尽可能接近“真实”版本号,以避免在部署多个版本时出现混淆。
#3
I have a tendency to prefix the groupId with my own usual groupId. This makes it absolutely clear that it's something I've uploaded, just in case it leaks out to the world at large.
我倾向于使用我自己常用的groupId为groupId添加前缀。这绝对清楚地表明它是我上传的内容,以防它泄漏到整个世界。
#4
Many sourceforge projects use the project's name in the groupid, eg:
许多sourceforge项目在groupid中使用项目的名称,例如:
GroupId net.sf.json-lib ArtifactId json-lib
GroupId net.sf.json-lib ArtifactId json-lib
This might be appropriate in the google example, as there are a lot of google artifacts.
这可能适用于谷歌示例,因为有很多谷歌文物。
Remember that you can use a classifer tag to differentiate between two jars at the same version but built for different purposes eg different JVMs.
请记住,您可以使用classifer标记来区分同一版本的两个jar,但是为不同目的而构建,例如不同的JVM。
#5
You might be in luck: Google has their own Maven repo for their projects. See this page: Instructions
你可能很幸运:Google为他们的项目拥有自己的Maven回购。见本页:说明
I had a few Jar files that were propietary, so I had to load them on each workstation (we don't have a company shared repo yet). I put them in the source code tree in a /lib directory (not always a good idea), and added a small .BAT file (or .sh script) that contained the mvn install-file commands to load my local machine's repo the first time I build. If I ever have to update these jars, I'll update the "load.bat" file also, and just rerun it. In my circumstance, I don't expect that to happen more than once a year, maybe less.
我有一些专属的Jar文件,所以我不得不在每个工作站上加载它们(我们还没有公司共享的回购)。我将它们放在/ lib目录中的源代码树中(并不总是一个好主意),并添加了一个包含mvn install-file命令的小.BAT文件(或.sh脚本)来加载我的本地机器的repo我建立的时间。如果我必须更新这些jar,我也会更新“load.bat”文件,然后重新运行它。在我的情况下,我不希望每年发生一次以上,也许更少。
#1
What you've done is pretty reasonable. A few extra points:
你做的很合理。一些额外的要点:
-
When Maven obtains an artifact from Nexus, the artifact is named as artifactId-version. GroupId is annoyingly omitted. So, when the artifact is moved around (say, copied into WEB-INF/lib in a web app), your jar file will read "gdata-analytics-1.0". That's usually not a problem. However, if the artifact name is very common, like "util", you may want to include group information inside the artifactId, such as using groupId of "com.google" and an artifactId of "com.google.gdata-analytics". Yes, the repitition is annoying, but it yields maximum clarity on the file system and in searches. I've actually had a problem where two different groupIds both had a "core-1.0" jar, and one overwrote the other when being copied into the lib directory at build time.
当Maven从Nexus获取工件时,该工件被命名为artifactId-version。 GroupId被省略了。因此,当工件移动(例如,复制到Web应用程序中的WEB-INF / lib)时,您的jar文件将显示为“gdata-analytics-1.0”。这通常不是问题。但是,如果工件名称非常常见,例如“util”,您可能希望在artifactId中包含组信息,例如使用“com.google”的groupId和“com.google.gdata-analytics”的artifactId。是的,重复是令人讨厌的,但它会在文件系统和搜索中产生最大的清晰度。我实际上有一个问题,其中两个不同的groupId都有一个“core-1.0”jar,一个在构建时被复制到lib目录时覆盖了另一个。
-
I second MattK's suggestion of aligning your Maven versionId with whatever version the artifact is commonly known by.
我的第二个MattK建议将你的Maven versionId与通常所知的工件版本对齐。
-
If you follow Dominic's advice of prefixing the groupId with your own company name (eg acme), it may make it easier to take advantage of Nexus' routing feature. It will ensure that requests for internal artifacts aren't propagated out to Maven Central and end up in their logs (which may be important if your groupId is "acme.secret.project"!
如果您遵循Dominic的建议,将groupId添加前缀为您自己的公司名称(例如acme),则可以更轻松地利用Nexus的路由功能。它将确保内部工件的请求不会传播到Maven Central并最终存储在他们的日志中(如果您的groupId是“acme.secret.project”,这可能很重要!
#2
I've been using Maven for about a year and have never run across a "standard" naming convention. I usually do exactly what you're doing, although I try to make the version number as close to the "real" version number as possible, just to avoid confusion in case I deploy multiple versions.
我已经使用Maven大约一年了,并且从未遇到过“标准”命名约定。我通常会做你正在做的事情,虽然我尽量使版本号尽可能接近“真实”版本号,以避免在部署多个版本时出现混淆。
#3
I have a tendency to prefix the groupId with my own usual groupId. This makes it absolutely clear that it's something I've uploaded, just in case it leaks out to the world at large.
我倾向于使用我自己常用的groupId为groupId添加前缀。这绝对清楚地表明它是我上传的内容,以防它泄漏到整个世界。
#4
Many sourceforge projects use the project's name in the groupid, eg:
许多sourceforge项目在groupid中使用项目的名称,例如:
GroupId net.sf.json-lib ArtifactId json-lib
GroupId net.sf.json-lib ArtifactId json-lib
This might be appropriate in the google example, as there are a lot of google artifacts.
这可能适用于谷歌示例,因为有很多谷歌文物。
Remember that you can use a classifer tag to differentiate between two jars at the same version but built for different purposes eg different JVMs.
请记住,您可以使用classifer标记来区分同一版本的两个jar,但是为不同目的而构建,例如不同的JVM。
#5
You might be in luck: Google has their own Maven repo for their projects. See this page: Instructions
你可能很幸运:Google为他们的项目拥有自己的Maven回购。见本页:说明
I had a few Jar files that were propietary, so I had to load them on each workstation (we don't have a company shared repo yet). I put them in the source code tree in a /lib directory (not always a good idea), and added a small .BAT file (or .sh script) that contained the mvn install-file commands to load my local machine's repo the first time I build. If I ever have to update these jars, I'll update the "load.bat" file also, and just rerun it. In my circumstance, I don't expect that to happen more than once a year, maybe less.
我有一些专属的Jar文件,所以我不得不在每个工作站上加载它们(我们还没有公司共享的回购)。我将它们放在/ lib目录中的源代码树中(并不总是一个好主意),并添加了一个包含mvn install-file命令的小.BAT文件(或.sh脚本)来加载我的本地机器的repo我建立的时间。如果我必须更新这些jar,我也会更新“load.bat”文件,然后重新运行它。在我的情况下,我不希望每年发生一次以上,也许更少。