Maven生成具有不同/过滤类的多个jar的最佳实践? [英] Maven best practice for generating multiple jars with different/filtered classes?

问题描述

我开发了一个Java实用程序库(类似于Apache Commons)，可在各种项目中使用. 除了胖客户端，我还将它用于移动客户端(具有J9 Foundation概要文件的PDA). 随着时间的流逝，从单个项目开始的库就分布在多个包中.结果，我最终获得了很多功能，而并不是所有项目中真正需要的功能.

I developed a Java utility library (similarly to Apache Commons) that I use in various projects. In addition to fat clients, I also use it for mobile clients (PDA with J9 Foundation profile). In time the library that started as a single project spread over multiple packages. As a result I end up with a lot of functionality, which is not really needed in all the projects.

由于该库还用于某些移动/PDA项目中，因此我需要一种方法来仅收集使用的类并生成实际的专用jar.

Since this library is also used inside some mobile/PDA projects I need a way to collect just the used classes and generate the actual specialized jars.

当前在使用该库的项目中，我有Ant jar任务，这些任务会(从实用程序项目中)生成专用的jar文件(例如:my-util-1.0-pda.jar，my-util-1.0-rcp .jar)使用包含/排除jar任务功能.对于移动项目，由于生成的jar文件的大小限制，通常需要这样做.

Currently in the projects that are using this library, I have Ant jar tasks that generate (from the utility project) the specialized jar files (ex: my-util-1.0-pda.jar, my-util-1.0-rcp.jar) using include/exclude jar task features. This is mostly needed due to the size constraints on the generated jar file, for the mobile projects.

现在迁移到Maven，我只是想知道是否有最佳实践可以达到类似目的.我考虑以下情况:

Migrating now to Maven I just wonder if there are any best practices to arrive to something similar. I consider the following scenarios:

[1] -除了主要jar工件( my-lib-1.0.jar )之外，还生成了 my-lib 项目内部使用分类器(例如: my-lib-1.0-pda.jar )使用Maven Jar插件或Maven组件插件过滤/包含独立/专门的工件.我对这种方法不太满意，因为它会因图书馆使用者的需求(过滤器)而污染图书馆.

[1] - additionally to the main jar artifact (my-lib-1.0.jar) also generating inside my-lib project the separate/specialized artifacts using classifiers (ex: my-lib-1.0-pda.jar) using Maven Jar Plugin or Maven Assembly Plugin filtering/includes. I'm not very comfortable with this approach since it pollutes the library with library consumers demands (filters).

[2] -为所有专用客户端/项目创建其他Maven项目，这些项目将包装""my-lib"并生成过滤的jar工件(例如: my -lib-wrapper-pda-1.0 ...等).结果，这些包装器项目将包括过滤(以生成过滤后的工件)，并且将仅取决于"my-lib"项目，而客户端项目将取决于 my-lib-wrapper-xxx-1.0 ，而不是 my-lib-1.0 .这种方法可能看起来有问题，因为即使这样会使"my-lib"项目保持完整(没有其他分类器和工件)，基本上也会使项目数量加倍，因为对于每个客户端项目，我都会有一个lib，仅用于收集所需的库"my-util"库中的类("my-pda-app"项目将需要"my-lib-wrapper-for-my-pda-app"项目/依赖项.)

[2] - Create additional Maven projects for all the specialized clients/projects, that will "wrap" the "my-lib" and generate the filtered jar artifacts (ex: my-lib-wrapper-pda-1.0 ...etc). As a result, these wrapper projects will include the filtering (to generate the filtered artifact) and will depend just on the "my-lib" project and the client projects will depend on my-lib-wrapper-xxx-1.0 instead of my-lib-1.0. This approach may look problematic since even that will let "my-lib" project intact (with no additional classifiers and artifacts), basically will double the number of projects since for every client project I'll have one lib, just to collect the needed classes from the "my-util" library ("my-pda-app" project will need a "my-lib-wrapper-for-my-pda-app" project/dependency).

[3] -在使用该库的每个客户端项目(例如: my-pda-app )中，添加一些专用的Maven插件以进行修整(在生成最终的工件/软件包)不需要的类(例如:maven-assembly-plugin，maven-jar-plugin，proguard-maven-plugin).

[3] - In every client project that uses the library (ex: my-pda-app) add some specialized Maven plugins to trim out (when generating the final artifact/package) the classes that are not required (ex: maven-assembly-plugin, maven-jar-plugin, proguard-maven-plugin).

以行家方式"解决此类问题的最佳实践是什么?

What is the best practice for solving this kind of problems in the "Maven way"?

推荐答案

出于模块化的考虑，Maven通用规则是每个POM一个主要工件"，并且一个不应该违反该约定的原因(通常)非常如何从一个项目创建两个JAR(以及为什么不应该这样做)博客文章.但是，有合理的例外(例如，一个仅产生接口的EJB项目生成一个EJB JAR和一个客户端EJB JAR).话虽如此:

The Maven general rule is "one primary artifact per POM" for the sake of modularity and the reasons one shouldn't break this convention (in general) are very well explained in the How to Create Two JARs from One Project (...and why you shouldn’t) blog post. There are however justified exceptions (for example an EJB project producing an EJB JAR and a client EJB JAR with only interfaces). Having said that:

提到的

The mentioned blog post (also check Using Maven When You Can't Use the Conventions) explains how you could implement Option 1 using separate profiles or the JAR plugin. If you decide to implement this solution, keep in mind that this should be an exception and that it might make dependency management trickier (and, as you mentioned, pollute the project with "client filtering logic"). Just in case, I would use several JAR plugin executions here.

选项2 与IMO 选项1 没什么不同(除了它将事物分开):基本上，拥有N个其他包装/过滤项目与拥有一个项目中有N个过滤规则.而且如果筛选有意义，我会选择选项1.

Option 2 isn't very different from Option 1 IMO (except that it separate things): basically, having N other wrapping/filtering projects is very similar with having N filtering rules in one project. And if filtering makes sense, I prefer Option 1.

我根本不喜欢选项3 ，因为我认为图书馆的客户清除"不需要的东西不应该成为责任.首先，客户端项目不一定具有必需的知识(要修整的知识)，其次，这可能与其他插件造成很大的混乱.

I don't like Option 3 at all because I think it shouldn't be the responsibility of a client of a library to "trim out" unwanted things. First, a client project doesn't necessarily have the required knowledge (what to trim) and, second, this might create a big mess with other plugins.

但，如果胖客户端不使用整个 my-lib (例如服务器端代码将需要整个EJB JAR) ，那么过滤并不是处理您情况的正确行家".正确的方法是选项4 :将所有常见的内容放入项目(产生 my-lib-core-1.0.jar )中，并将特定项目的特定部分放入其中(将产生 my-lib-pda-1.0.jar 等).然后，客户将依赖于核心工件和专门的工件.

BUT if the fat clients are not using the whole my-lib (like server-side code would require the whole EJB JAR), then filtering isn't the right "maven way" to handle your situation. The right way would be Option 4: put everything common in a project (producing my-lib-core-1.0.jar) and specific parts in specific projects (that will produce my-lib-pda-1.0.jar etc). Clients would then depend on the core artifact and specialized ones.

这篇关于Maven生成具有不同/过滤类的多个jar的最佳实践?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！