eclipse 在多个项目之间共享 JAR 的最佳方式是什么？

What's the best way to share JARs across multiple projects?

提问by JR.

When you have multiple projects that all use the same set of JAR libraries, it's tedious to include the same JARs over and over again with each project. If I'm working on 20 different projects, I'd rather not have 20 of the same exact set of JAR files lying around. What's the best way to make all those projects (and new projects as well) reference the same set of JARs?

当您有多个项目都使用相同的 JAR 库集时，在每个项目中一遍又一遍地包含相同的 JAR 是很乏味的。如果我正在处理 20 个不同的项目，我宁愿没有 20 个完全相同的 JAR 文件集。使所有这些项目（以及新项目）引用同一组 JAR 的最佳方法是什么？

I have some ideas, but each of them has some disadvantages:

我有一些想法，但每个想法都有一些缺点：

• Place all the JARs in a folder and have each project look in that folder.
• Using Eclipse, create a "User Library" and have each project reference that user library.
• Create a "Library" project that references each JAR, and have each project reference that library project.

• 将所有 JAR 文件放在一个文件夹中，并让每个项目都在该文件夹中查找。
• 使用 Eclipse，创建一个“用户库”并让每个项目引用该用户库。
• 创建一个引用每个 JAR 的“库”项目，并让每个项目引用该库项目。

采纳答案by Robert Munteanu

Use Mavenor Ivyto handle these shared jars. If you're wary of changing your projects too much, you can simply use Ivyto manage the extra classpath for you.

使用Maven或Ivy来处理这些共享的 jar。如果您担心过多地更改项目，则可以简单地使用Ivy为您管理额外的类路径。

---

---

Both have good Eclipse plugins:

两者都有很好的 Eclipse 插件：

m2eclipse

日食

Maven classpath container http://img229.imageshack.us/img229/4848/mavendependencies.png

Maven 类路径容器 http://img229.imageshack.us/img229/4848/mavendependencies.png

IvyDE

常春藤DE

IvyDE classpath container http://img76.imageshack.us/img76/3180/cpnode.jpg

IvyDE 类路径容器 http://img76.imageshack.us/img76/3180/cpnode.jpg

which I've used with good results.

我用过的效果很好。

You'll note that both of them reference jars outsidethe workspace, so the duplication is removed.

您会注意到它们都引用了工作区之外的jar ，因此删除了重复项。

---

---

Update( prompted by comments ):

更新（由评论提示）：

My reason for recommending this approach is that I strongly believe that it's simpler and clearer to declaredependencies rather then manually include them. There is a small one-time cost associated with this - smaller for Ivy than for Maven - but in the long run it does pay off.

我推荐这种方法的原因是我坚信声明依赖关系比手动包含它们更简单、更清晰。与此相关的一次性成本很小——Ivy 比 Maven 小——但从长远来看，它确实有回报。

Another, smaller, benefit is the handling of transitive and conflicting dependencies. It's easy to forget whyyou need that commons-logging-1.1.jar in the classpath and whether you need to upgrade to 1.1.1. And also it's no fun to pull in all the depencies required for e.g.a Hibernate + Annotation + Spring combo. Focus on programming, not building.

另一个较小的好处是处理传递和冲突的依赖关系。很容易忘记为什么在类路径中需要 commons-logging-1.1.jar 以及是否需要升级到 1.1.1。而且这是没有乐趣，以拉在所有所需的depencies如一个Hibernate +注释+弹簧组合。专注于编程，而不是构建。

回答by Kevin Stembridge

Believe it or not, your 'tedious' approach is probably the simplest, cleanest and least time-consuming approach there is.

信不信由你，你的“乏味”方法可能是最简单、最干净和最耗时的方法。

Before jumping on the maven bandwagon you should consider what is really wrong with doing things the way you are currently doing them. You mentioned that it is tedious and that you have a lot of jar files lying around. I created the build process on a large multi-module project using Maven then spent the next 18 months battling with it constantly. Believe me it was tedious and there were a lot of jar files lying around.

在加入 Maven 潮流之前，您应该考虑以目前的方式做事有什么问题。你提到它很乏味，而且你有很多 jar 文件。我使用 Maven 在一个大型多模块项目上创建了构建过程，然后在接下来的 18 个月里不断地与它作斗争。相信我，这很乏味，而且周围有很多 jar 文件。

Since going back to Ant and committing jars to source control alongside the projects that use them it has been a much smoother ride.

自从回到 Ant 并将 jars 与使用它们的项目一起提交到源代码控制以来，它已经变得更加顺畅了。

I store a bunch of jar files in a single directory on my machine and then when I create a new project or need to add a new jar to an existing project it only takes about 30 seconds:

我将一堆 jar 文件存储在我机器上的单个目录中，然后当我创建一个新项目或需要向现有项目添加一个新 jar 时，它只需要大约 30 秒：

• Copy the jar from JAR_REPO to project lib dir.
• Add jar to build.properties
• Add jar to classpath in build.xml
• Add jar to build path in Eclipse.

• 将 jar 从 JAR_REPO 复制到项目 lib 目录。
• 将 jar 添加到 build.properties
• 将 jar 添加到 build.xml 中的类路径
• 添加 jar 以在 Eclipse 中构建路径。

Over the course of a project, that 30 seconds is insignificant, but it means I have a project that can be checked out of source control and just works without requiring any custom Eclipse configuration or Maven installations or user-specific setup.

在一个项目的过程中，这 30 秒是微不足道的，但这意味着我有一个可以从源代码管理中检出的项目，并且无需任何自定义 Eclipse 配置或 Maven 安装或特定于用户的设置即可工作。

This approach has saved me and my project team a huge amount of time, mainly because it is simple, reliable and easy to understand.

这种方法为我和我的项目团队节省了大量时间，主要是因为它简单、可靠且易于理解。

---

---

Update: Clarification prompted by comments

更新：评论提示的澄清

@Robert Munteanu: Thanks for the feedback and updated comments. This might sound a bit argumentative but I'm afraid I can't agree with you that Maven is simpler and clearer, or that it will save you time in the long run.

@Robert Munteanu：感谢您的反馈和更新的评论。这听起来可能有点争论，但恐怕我不能同意您的观点，即 Maven 更简单、更清晰，或者从长远来看它会节省您的时间。

From your posting:
"I strongly believe that it's simpler and clearer to declare dependencies rather then manually include them. There is a small one-time cost associated with this - smaller for Ivy than for Maven - but in the long run it does pay off."

来自您的帖子：
“我坚信声明依赖项而不是手动包含它们更简单、更清晰。与此相关的一次性成本很小——Ivy 比 Maven 小——但从长远来看，它确实有回报.”

It may be easier to have Maven download a jar file for you than having to download it yourself but that's the only advantage. Otherwise Maven is not simpler, not clearer and its complexities and limitations will cost you in the long run.

让 Maven 为您下载 jar 文件可能比必须自己下载更容易，但这是唯一的优势。否则 Maven 不会更简单、更清晰，从长远来看，它的复杂性和局限性会让您付出代价。

Clarity

明晰

The two dependency declarations below do the same thing. I find the Ant one much clearer than the Maven one.

下面的两个依赖声明做同样的事情。我发现 Ant 比 Maven 清晰得多。

Ant Style:

蚂蚁风格：

<path id="compile.classpath">  
    <pathelement location="${log4j.jar}" />
    <pathelement location="${spring.jar}" />
</path>  

Maven Style:

马文风格：

<dependency>
    <groupId>log4j</groupId>
    <artifactId>log4j</artifactId>
    <version>${log4j.version}</version>
    <scope>compile</scope>
</dependency>

<dependency>
    <groupId>org.springframework</groupId>
    <artifactId>spring</artifactId>
    <version>${spring.version}</version>
    <scope>compile</scope>
</dependency>

Simplicity

简单

With the Ant version you can hover over the ${log4j.jar} property and it will show you the absolute path to the jar file. You can search for usage of compile.classpath. There's not a whole lot more you need to know.

在 Ant 版本中，您可以将鼠标悬停在 ${log4j.jar} 属性上，它会显示 jar 文件的绝对路径。您可以搜索 compile.classpath 的用法。你需要知道的并不多。

There is no question that Maven is more complex than the approach I'm suggesting. When you start out with Maven these are just some of the questions that need to be answered.

毫无疑问，Maven 比我建议的方法更复杂。当您开始使用 Maven 时，这些只是需要回答的一些问题。

• What does groupId mean?
• What does artifactId mean?
• Where does the jar come from?
• Where is the jar now?
• What is provided scope? Who's providing it?
• How did that jar file end up in my WAR file?
• Why does this dependency not have a version element?
• I don't understand this error message. What on Earth does it mean?
• Where on Earth did that jar file come from? I didn't declare it.
• Why do I have 2 versions of the same jar file on my classpath?
• Why does the project not build any more? Nothing has changed since the last time I built it.
• How do I add a third-party jar that's not in the Maven repository?
• Tell me again where I get that Eclipse plugin from.

• groupId 是什么意思？
• artifactId 是什么意思？
• 罐子从哪里来？
• 罐子现在在哪里？
• 提供的范围是什么？谁提供？
• 该 jar 文件是如何出现在我的 WAR 文件中的？
• 为什么这个依赖没有版本元素？
• 我不明白这个错误信息。这到底是什么意思？
• 这个 jar 文件到底来自哪里？我没有申报。
• 为什么我的类路径上有 2 个版本的同一个 jar 文件？
• 为什么该项目不再构建？自从我上次构建它以来，一切都没有改变。
• 如何添加不在 Maven 存储库中的第三方 jar？
• 再告诉我我从哪里得到 Eclipse 插件。

Transitive Dependencies

传递依赖

"Another, smaller, benefit is the handling of transitive and conflicting dependencies."

“另一个较小的好处是处理传递和冲突的依赖关系。”

In my experience, transitive dependencies are more trouble than they're worth. You end up with multiple versions of the same jar file and you end up with optional jar files that you don't want. I ended up declaring just about everything with provided scope to avoid the hassle.

根据我的经验，传递依赖比它们的价值更麻烦。您最终会得到同一个 jar 文件的多个版本，并且最终会得到您不想要的可选 jar 文件。我最终声明了几乎所有具有提供范围的内容以避免麻烦。

The Long Term Payoff

长期回报

"Focus on programming, not building."

“专注于编程，而不是构建。”

I agree. Since going back to Ant and putting my jar files in source control I have been able to spend farless time dealing with build issues.

我同意。由于源代码控制回去蚂蚁和把我的jar文件我已经能够花费远远更少的时间来处理构建的问题。

These are the things I spend less time doing:

这些是我花更少时间做的事情：

• Reading poor Maven documentation.
• Reading even poorer Codehaus Mojo documentation.
• Setting up shared internal repositories.
• Educating team members.
• Writing Maven plugins to fill the gaps.
• Trying to workaround defective plugins (release, assembly).
• Installing Eclipse plugins for Maven.
• Waiting for the plugin to give me back control of Eclipse.

• 阅读糟糕的 Maven 文档。
• 阅读更糟糕的 Codehaus Mojo 文档。
• 设置共享的内部存储库。
• 教育团队成员。
• 编写 Maven 插件来填补空白。
• 尝试解决有缺陷的插件（发布、组装）。
• 为 Maven 安装 Eclipse 插件。
• 等待插件让我重新控制 Eclipse。

Anyways, sorry about the long posting. Maybe now that I've got that off my chest I can bring some closure to my long and painful Maven experience. :)

无论如何，很抱歉发布了很长的帖子。也许现在我已经摆脱了我的胸怀，我可以为我漫长而痛苦的 Maven 经历带来一些结束。:)

回答by dimo414

It depends on your needs, but there are several viable options. My work uses an external folder and all projects reference that folder, which makes life easier running builds outside of eclipse. A user library is a slightly more plesant way of doing things, as long as you don't mind the slight eclipse dependancy. I don't see a whole lot of benefit to a library project on it's own, but if you have some sort of universal 'util' type project that all other projects already load, you could just put all the external jars in that project.

这取决于您的需求，但有几种可行的选择。我的工作使用一个外部文件夹，所有项目都引用该文件夹，这使得在 eclipse 之外运行构建变得更容易。只要您不介意轻微的 eclipse 依赖性，用户库是一种稍微令人愉快的做事方式。我没有看到库项目本身有很多好处，但是如果您有某种通用的“util”类型项目并且所有其他项目都已经加载，您可以将所有外部 jar 放在该项目中。

回答by dimo414

One approach is to put all your jar files in one location on your machine, in your eclipse ide, define an environment variable, say LIB_LOCATION that points to that directory and have your projects use the jars relative to that variable. This way, you get the ease of use, no multiple jars, portable across machines, as long as you have the variable defined correctly. I have been trying maven for a group of decent size projects and it seems I have to fight at least as much as I used to. Bugs and wired behaviors in the plug ins, m2eclipse and q4eclipse.

一种方法是将所有 jar 文件放在您机器上的一个位置，在您的 eclipse ide 中，定义一个环境变量，比如指向该目录的 LIB_LOCATION，并让您的项目使用相对于该变量的 jar。这样，您就可以轻松使用，无需多个 jar，可跨机器移植，只要您正确定义了变量。我一直在为一组体面的项目尝试 maven，看来我必须至少像以前一样努力。插件、m2eclipse 和 q4eclipse 中的错误和有线行为。

回答by Thorbj?rn Ravn Andersen

We have decided on a more tedious method but which allows us to have everything inhouse, but will probably only work well for a small set of developers.

我们决定采用一种更乏味的方法，但它允许我们在内部拥有所有内容，但可能只适用于一小部分开发人员。

Each set of jar files is set up as a Eclipse project named appropriately after the jar set, added to the build path, source jars and javadoc jars correctly set on each jar in the build path, and each project then includes those library projects needed for that project. The resulting multi-project workspace is then exported as a ProjectSet.psf file which can then be read in in a raw Eclipse bringing in the whole workspace again. We then have all the above projects in CVS including the jar files.

每组 jar 文件都设置为一个以 jar 集命名的 Eclipse 项目，添加到构建路径中，在构建路径中的每个 jar 上正确设置源 jar 和 javadoc jar，然后每个项目都包含那些需要的库项目那个项目。然后将生成的多项目工作区导出为 ProjectSet.psf 文件，然后可以在原始 Eclipse 中读取该文件，从而再次引入整个工作区。然后我们在 CVS 中拥有上述所有项目，包括 jar 文件。

This has worked very wellf or us.

这对我们来说效果很好。

If you are in a larger organization the dependency handling in Maven may work well for you. You should definitively have a local cache of artifacts so the whole world doesn't stop if your internet connection is lost.

如果你在一个更大的组织中，Maven 中的依赖处理可能适合你。您绝对应该拥有一个本地的工件缓存，这样即使您的互联网连接丢失，整个世界也不会停止。

Also note that the new Eclipse 3.5 coming out this sommer, will have a "Create Runnable Jar" which can output the needed jars next to the generated runnable jar and set up the Class-PAth line in the Manifest correctly. I expect that to be a big time saver - check it out.

另请注意，今年夏天推出的新 Eclipse 3.5 将有一个“创建可运行 Jar”，它可以在生成的可运行 jar 旁边输出所需的 jar，并在清单中正确设置 Class-PAth 行。我希望这可以节省大量时间 - 检查一下。

回答by akarnokd

You might edit the "Installed JREs" to include your JAR file ("Add external JARs"), add the file to jdk\jre\lib\ext\ directory or specify a CLASSPATH environment variable containing the path to it.

您可以编辑“已安装的 JRE”以包含您的 JAR 文件（“添加外部 JAR”），将文件添加到 jdk\jre\lib\ext\ 目录或指定包含其路径的 CLASSPATH 环境变量。

回答by Scott Stanchfield

I'd recommend the "library" project approach.

我推荐“图书馆”项目方法。

But even better -- a separate lib project per external jar -- this allows you to track deps between third-party jars and know what needs to change when you're upgrading a dependency.

但更好的是——每个外部 jar 有一个单独的 lib 项目——这允许您跟踪第三方 jar 之间的 deps，并知道在升级依赖项时需要更改什么。

Make sure you check in these projects so all users are using the same versions of third-party libs and so you can easily regenerate a version of software (use tags/labels in your version control to group which versions of which projects go together)

确保您签入这些项目，以便所有用户都使用相同版本的第三方库，这样您就可以轻松地重新生成软件版本（在版本控制中使用标签/标签将哪些项目的哪些版本组合在一起）