Java 项目：应该将 .classpath .project 文件提交到存储库中吗？

Java project: should .classpath .project file be committed into repository?

提问by sean

Should I check in my .project and .classpath files?

我应该检查我的 .project 和 .classpath 文件吗？

My friend told me that I should only check in .java files and the build.xml to guarantee portability. He said ".classpath will cause you much less portability on different environment. .project is entirely your local eclipse setting"

我的朋友告诉我，我应该只检查 .java 文件和 build.xml 以保证可移植性。他说“.classpath 会导致你在不同环境下的可移植性大大降低。.project 完全是你的本地 eclipse 设置”

I agree with him, but partially.

我同意他的看法，但部分同意。

-- Not checking in .project file will make my development less efficient (I can't simply "import" a project code from a directory)

-- 不签入 .project 文件会使我的开发效率降低（我不能简单地从目录“导入”项目代码）

-- Not checking in .classpath file seems OK to me (?) if my build.xml is written carefully.

-- 如果我的 build.xml 写得很仔细，不检查 .classpath 文件对我来说似乎没问题（？）。

Anyone wants to share their experience here?

有人想在这里分享他们的经验吗？

回答by tangens

There is nothing wrong with checking in .projectand .classpath. I would do so, if your build.xmlisn't able to create both of the files for you. As you said, it's uncomfortable to miss these files when you try to create a new eclipse workspace.

签入.project和没有任何问题.classpath。如果您build.xml无法为您创建这两个文件，我会这样做。正如您所说，当您尝试创建一个新的 eclipse 工作区时，错过这些文件是很不舒服的。

Before you check in .classpathyou should be sure that there is no absolute path in it. Convert it into a relative one with a text editor.

在您签入之前，.classpath您应该确保其中没有绝对路径。使用文本编辑器将其转换为相对的。

Edit:Or even better, use eclipse classpath variables in your otherwise absolute pathes, like @taylor-leese commented.

编辑：或者更好的是，在您的其他绝对路径中使用 eclipse 类路径变量，如@taylor-leese 评论。

回答by MikeTheReader

One thing I would caution against with checking in .classpath file is make sure you don't reference files outside of your project. Eclipse stores the location of these files with a full filepath, and you would need to make sure other developers had those files in exactly the same place.

签入 .classpath 文件时我要警告的一件事是确保不要引用项目之外的文件。Eclipse 使用完整的文件路径存储这些文件的位置，您需要确保其他开发人员将这些文件放在完全相同的位置。

回答by mhshams

Not checking in .project file will make my development less efficient (I can't simply "import" a project code from a directory)

不签入 .project 文件会使我的开发效率降低（我不能简单地从目录“导入”项目代码）

for this issue, you can choose to create new project and import existing source.

对于这个问题，您可以选择创建新项目并导入现有源。

one issue with IDE specific files like .project is that other Developers may want to use another IDE do develop the project, so they may add another type of project files. this will make your repo messy.

.project 等 IDE 特定文件的一个问题是其他开发人员可能希望使用另一个 IDE 来开发项目，因此他们可能会添加另一种类型的项目文件。这会让你的回购变得混乱。

回答by Eugene Ryzhikov

There is not problem of checking in .classpath and .project files into repository. It will help developers which use Eclipse to get going faster.

将 .classpath 和 .project 文件签入存储库没有问题。它将帮助使用 Eclipse 的开发人员更快地进行。

Warning: Make sure your .classpath file is referencing only artifacts which either checked into the repository with the project or can be obtained automatically (such as maven artifacts).

警告：确保您的 .classpath 文件仅引用那些随项目签入存储库或可以自动获取的工件（例如 maven 工件）。

回答by YoK

I would prefer to checkin .project and .classpath.

我更愿意签入 .project 和 .classpath。

This would be helpful when this project is being shared by multiple developers.It becomes easy and faster to setup development env.by simply importing this as existing project on any system using eclipse.

当多个开发人员共享此项目时，这将很有帮助。设置开发环境变得容易和快捷。通过简单地将其作为现有项目导入到任何使用 eclipse 的系统上。

Only caution needs to be taken here is classpath's are relative to project.

这里唯一需要注意的是类路径是相对于项目的。

回答by Colin Hebert

I don't really know eclipse preferences files, but with IntelliJ, those files are OS agnostics, which means that it won't ruin your portability. Unless you define libraries with a full path to your system (That would be pretty dangerous/stupid).

我真的不知道 eclipse 首选项文件，但是使用 IntelliJ，这些文件与操作系统无关，这意味着它不会破坏您的可移植性。除非您使用系统的完整路径定义库（那将非常危险/愚蠢）。

When you share preferences, you're sure that everyone will work with the same conditions on the project (plugins configuration, encoding, profiles [for intelliJ]) which can really be a good thing.

当您共享首选项时，您确信每个人都会在项目中使用相同的条件（插件配置、编码、配置文件 [intelliJ]），这确实是一件好事。

It doesn't bother me when some Eclipse files are here, and I think it shouldn't/doesn't really bother other developers when some hidden files just lay there.

当一些 Eclipse 文件在这里时它不会打扰我，我认为当一些隐藏文件放在那里时它不应该/不会真正打扰其他开发人员。

回答by Thorbj?rn Ravn Andersen

We check in .project and .classpath. With ProjectSet's this allows us to check out complex workspaces with a single "Import Team ProjectSet"

我们检查 .project 和 .classpath。使用 ProjectSet，这允许我们使用单个“导入团队项目集”检查复杂的工作区

回答by Dominic Mitchell

The key question with all such files is "Can they be reproduced automatically?" If not, check them into source control.

所有此类文件的关键问题是“它们可以自动复制吗？” 如果没有，请将它们检查到源代码管理中。

In this case, I'd say "yes," unless you're using maven, which has m2eclipse and the eclipse plugin to generate them for you.

在这种情况下，我会说“是”，除非您使用的是 maven，它具有 m2eclipse 和 eclipse 插件可以为您生成它们。

回答by Nick G.

For my 2 cents, I would rate it as a bad practice. Projects should not be tied to an IDE, and especially should not be tied to a specific version of an IDE.

对于我的 2 美分，我认为这是一种不好的做法。项目不应与 IDE 相关联，尤其不应与特定版本的 IDE 相关联。

Checking in Eclipse config files might work well for simpler and short-term projects. For larger projects that are developed over several years this will generally cause more hassle, as IDE versions change, and project config files don't. Just imagine checking in a 2 year old branch with Eclipse 2.0 config files in Eclipse 4.3 with some customized libraries and m2e integration... No fun at all...

检查 Eclipse 配置文件可能适用于更简单和短期的项目。对于多年开发的大型项目，这通常会造成更多麻烦，因为 IDE 版本会发生变化，而项目配置文件不会。想象一下，在 Eclipse 4.3 中使用 Eclipse 2.0 配置文件签入一个 2 岁的分支，其中包含一些自定义库和 m2e 集成......一点都不好玩......

回答by iago-lito 'considering leaving

I often have a similar, more general questionning. The problem essentially is :

我经常有类似的，更笼统的问题。问题本质上是：

• which files am I commiting for me?
• which files am I commiting for others?
• → How do I combine both objectives of "versionning"?

• 我要为我提交哪些文件？
• 我为其他人提交了哪些文件？
• → 如何结合“版本控制”的两个目标？

I offered discussing this there, so you may find more details about the problem, along with interesting solutions :)

我提议在那里讨论这个问题，因此您可能会找到有关该问题的更多详细信息以及有趣的解决方案:)

---

---

The one I like best is the use of git submodule: keep your .projectfiles etc.in a private commit repo. And make your final, pure, essential srcproduction into a neat submodulenugget: a public repo.

我最喜欢的是使用git submodule: 将您的.project文件等保存在私人提交存储库中。并将您最终的、纯粹的、必不可少的src作品变成一个整洁的submodule金块：公共回购。

project/ # root module
|   .git # private repo
|   .project
|   .classpath
|   momsNumber.txt
+---src/     # submodule
|   |   .git # public repo
|   |   main.java
|   +---package/
|   |   |    Etc.java

---

---

See there anyway.

随便看看那里。