如何在 Maven 中使用或滥用工件分类器？
我们目前正在尝试将一个用 ant 构建的非常（非常）大的项目移植到 maven（同时也迁移到 svn）。在重塑项目结构以最适合 Maven 范式时正在探索所有可能性。
现在更具体地说，我遇到了分类器，想知道如何利用它们来发挥我的优势，同时避免“分类器反模式”。
感谢
：http://maven.apache.org/pom.html
分类器：您偶尔可能会在分类器上找到第五个元素 坐标，这就是分类器。我们将访问分类器 稍后，但现在只要知道这些类型的项目就足够了 显示为 groupId:artifactId:packaging:classifier:version。
和
分类器可以区分构建自的工件 相同的 POM，但内容不同。这是一些可选的和 任意字符串（如果存在）附加到工件名称 就在版本号之后。作为这个元素的动机， 例如，考虑一个提供针对 JRE 的工件的项目 1.5，但同时也是仍然支持 JRE 1.4 的工件。第一个工件可以配备分类器 jdk15 和 第二个是jdk14，这样客户可以选择使用哪一个。
分类器的另一个常见用例是需要附加 项目主要工件的次要工件。如果您浏览 Maven 中央存储库，您会注意到分类器来源 和javadoc用于部署项目源代码和API文档 以及打包的类文件。
We are currently attempting to port a very (very) large project built with ant to maven (while also moving to svn). All possibilities are being explored in remodeling the project structure to best fit the maven paradigm.
Now to be more specific, I have come across classifiers and would like to know how I could use them to my advantage, while refraining from "classifier anti-patterns".
Thanks
from: http://maven.apache.org/pom.html
classifier: You may occasionally find a fifth element on the
coordinate, and that is the classifier. We will visit the classifier
later, but for now it suffices to know that those kinds of projects
are displayed as groupId:artifactId:packaging:classifier:version.
and
The classifier allows to distinguish artifacts that were built from
the same POM but differ in their content. It is some optional and
arbitrary string that - if present - is appended to the artifact name
just after the version number. As a motivation for this element,
consider for example a project that offers an artifact targeting JRE
1.5 but at the same time also an artifact that still supports JRE 1.4. The first artifact could be equipped with the classifier jdk15 and the
second one with jdk14 such that clients can choose which one to use.Another common use case for classifiers is the need to attach
secondary artifacts to the project's main artifact. If you browse the
Maven central repository, you will notice that the classifiers sources
and javadoc are used to deploy the project source code and API docs
along with the packaged class files.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
我认为正确的问题是
如何使用或滥用附加工件maven？因为基本上这就是引入分类器的原因 - 允许您发布附加工件。嗯，Maven 项目通常隐式使用附加的工件，例如通过使用 maven-javadoc-plugin 或 maven-source-plugin。 maven-javadoc-plugin 使用
javadoc分类器发布包含生成文档的附加工件，maven-source-plugin 使用sources分类器发布源。现在附加工件的显式使用怎么样？我使用附加的工件来发布harness shell 脚本（start.sh 和Co）。使用分类器
sql或类似的东西在附加工件中发布 SQL 脚本也是一个好主意。如何将任意工件附加到分类器上？ - 这可以通过 build-helper-maven-plugin 来完成。
I think the correct question would be
How to use or abuse attached artifacts maven?Because basicaly that is why classifiers are introduced - to allow you to publish attached artifacts.Well, Maven projects often implicitely use attached artifacts, e.g. by using maven-javadoc-plugin or maven-source-plugin. maven-javadoc-plugin publishes attached artifact that contains generated documentation by using a
javadocclassifier, and maven-source-plugin publishes sources by usingsourcesclassifier.Now what about explicit usage of attached artifacts? I use attached artifacts to publish harness shell scripts (start.sh and Co). It's also a good idea to publish SQL scripts in the attached artifact with a classifier
sqlor something like that.How can you attach an arbitary artifact with your classifier? - this can be done with build-helper-maven-plugin.
不要使用它们。它们是可选和任意。
如果您正在将项目移植到 Maven，请保持简单，只做必要的事情（首先）以使一切按您希望的方式工作。然后，当一切按照您想要的方式工作后，您可以探索 Maven 的更高级功能来完成很酷的事情。
这个答案是基于你的问题，听起来像是“这个功能听起来很不错，即使我不需要它，我该如何使用它？”类似的问题。如果您需要此功能，请更新您的问题，并提供有关您如何考虑使用分类器功能的更多信息，我们将获得更多信息来为您提供帮助。
Don't use them. They are optional and arbitrary.
If you are in the middle of porting a project over to maven, keep things simple and only do what is necessary (at first) to get everything working as you'd like. Then, after things are working like you want, you can explore more advanced features of maven to do cool stuff.
This answer is based on your question sounding like a "This features sounds neat, how can I use it even though I don't have a need for it?" kind of question. If you have a need for this feature, please update your question with more information on how you were thinking of utilizing the classifier feature and we will all be more informed to help you.
与 Jesse Web 的答案相反，了解分类器是件好事，这样您就可以利用它们并避免除了移植到 Maven 之外还必须重构代码。一两年前我们经历了同样的过程。以前，我们将所有内容都放在一个代码库中，并与 ant 一起构建。在迁移到maven的过程中，我们还发现需要将各个组件分解到自己的maven项目中。其中一些项目实际上是库，但有一些 Web 资源（jsp、js、图像等）。最终结果是我们使用分类器“web-resources”和类型“war”（用作覆盖）使用 Web 资源创建附加工件（如 @Male 提到的）。这在当时是，并且在更好地理解 Maven 之后仍然是移植旧的、耦合的项目的最佳解决方案。我们最终希望将这些网络资源分开，因为它们不属于这个库，但至少它可以作为单独的任务来完成。
一般来说，您希望避免附加工件。这通常表明应该创建一个单独的项目来构建该工件。我建议您在任何时候想要将工件与单独的分类器附加在一起时考虑这样做。
In contrast to Jesse Web's answer, it is good to learn about classifiers so that you can leverage them and avoid having to refactor code in addition to porting to maven. We went through the same process a year or two ago. Previously we had everything in one code base and built together with ant. In migrating to maven, we also found the need to break out the various components into their own maven projects. Some of these projects were really libraries, but had some web resources (jsp, js, images, etc.). The end result was us creating an attached artifact (as mentioned by @Male) with the web resources, using the classifier "web-resources" and the type "war" (to use as an overlay). This was then, and still does after understanding maven better, the best solution to port an old, coupled, project. We are eventually wanting to separate out these web resources since they don't belong in this library, but at least it can be done as a separate task.
In general, you want to avoid having attached artifacts. This is typically a sign that a separate project should be created to build that artifact. I suggest looking at doing this anytime you are tempted to attach an artifact with a separate classifier.
我使用分类器来定义主要工件的支持工件。
例如，我有 com.bar|foo-1.0.war 并有一些名为 com.bar|foo-1.0-properties.zip 的关联配置
I use classifiers to define supporting artefacts to the main artefact.
For example I have com.bar|foo-1.0.war and have some associated config called com.bar|foo-1.0-properties.zip
当您想要将同一工件的不同版本部署到存储库时，您可以使用分类器。
这是一个用例：
我将它们与 pom.xml 中的属性结合使用。 pom 有默认值，可以通过命令行覆盖。不带选项运行使用默认属性值。如果我构建具有不同属性值的工件版本，我可以使用分类器将其部署到存储库。
例如，命令：
构建具有特殊属性的耳朵工件的版本，并使用分类器“specialVersion”将该工件部署到我的存储库。
因此，我的存储库可以有 my-ear-1.0.0.ear 和 my-ear-1.0.0-specialVersion.ear。
You can use classifers when you have different versions of the same artifact that you want to deploy to your repository.
Here's a use case:
I use them in conjunction with properties in a pom. The pom has default values which can be overriden via the command line. Running without options uses the default property value. If I build a version of the artifact with different property values, I can deploy that to the repo with a classifier.
For example, the command:
Builds a version of an ear artifact with special properties and deploys the artifact to my repo with a classifier "specialVersion".
So, my repo can have my-ear-1.0.0.ear and my-ear-1.0.0-specialVersion.ear.