Java 项目:应将 .classpath .project 文件提交到存储库中吗? [复制]
Posted
技术标签:
【中文标题】Java 项目:应将 .classpath .project 文件提交到存储库中吗? [复制]【英文标题】:Java project: should .classpath .project file be committed into repository? [duplicate] 【发布时间】:2011-04-06 10:03:41 【问题描述】:我应该签入我的 .project 和 .classpath 文件吗?
我的朋友告诉我,我应该只签入 .java 文件和 build.xml 以保证可移植性。他说“.classpath 会导致你在不同环境中的可移植性大大降低。.project 完全是你的本地 eclipse 设置”
我同意他,但部分同意。
-- 不签入 .project 文件会降低我的开发效率(我不能简单地从目录中“导入”项目代码)
-- 如果我的 build.xml 写得很仔细,我觉得不签入 .classpath 文件似乎没问题(?)。
有人想在这里分享他们的经验吗?
【问题讨论】:
请注意,如果您使用 Maven 和 m2eclipse 插件,您可能不需要来自.project
或 .classpath
的任何设置。 “import maven project”和“checkout maven project”仅适用于pom.xml
。
【参考方案1】:
签入.project
和.classpath
并没有错。如果您的 build.xml
无法为您创建这两个文件,我会这样做。正如您所说,当您尝试创建新的 Eclipse 工作区时,错过这些文件会让人不舒服。
在您签入.classpath
之前,您应该确保其中没有绝对路径。使用文本编辑器将其转换为相对的。
编辑: 或者更好的是,在其他绝对路径中使用 eclipse 类路径变量,例如 @taylor-leese 评论。
【讨论】:
只使用 Eclipse 类路径变量而不是相对路径。【参考方案2】:对于我的 2 美分,我认为这是一种不好的做法。项目不应绑定到 IDE,尤其不应绑定到特定版本的 IDE。
签入 Eclipse 配置文件可能适用于更简单和短期的项目。对于经过数年开发的大型项目,这通常会带来更多麻烦,因为 IDE 版本会发生变化,而项目配置文件不会。试想一下,在 Eclipse 4.3 中使用 Eclipse 2.0 配置文件签入一个 2 年历史的分支,其中包含一些自定义库和 m2e 集成......一点也不好玩......
【讨论】:
【参考方案3】:我在签入 .classpath 文件时要注意的一件事是确保您不引用项目之外的文件。 Eclipse 使用完整的文件路径存储这些文件的位置,您需要确保其他开发人员将这些文件放在完全相同的位置。
【讨论】:
同意,但这可以通过使用 Eclipse 类路径变量来避免。这样,每个开发人员的 .classpath 文件可以保持不变,他们只需修改特定机器的类路径变量。【参考方案4】:所有此类文件的关键问题是“它们可以自动复制吗?”如果没有,请将它们签入源代码管理。
在这种情况下,我会说“是”,除非您使用的是 maven,它具有 m2eclipse 和 eclipse 插件来为您生成它们。
【讨论】:
我认为您的意思是“在这种情况下,我会说'不,它们不能自动复制,'” 我同意你的意思。如所写,您有两个问题。隐含的问题:“我应该检查它们吗?”还有一个明确的问题:“它们可以自动复制吗?”因此,当您说“是”时,您的意思是隐含的问题。 所以澄清一下:如果您使用的是 maven,那么您不需要提交这些文件(.project、.classpath)?【参考方案5】:我真的不知道 Eclipse 首选项文件,但使用 IntelliJ,这些文件与操作系统无关,这意味着它不会破坏您的可移植性。除非您定义具有系统完整路径的库(那将非常危险/愚蠢)。
当您分享偏好时,您确信每个人都会在项目上使用相同的条件(插件配置、编码、配置文件 [for intelliJ]),这确实是一件好事。
当一些 Eclipse 文件在这里时它不会打扰我,而且我认为当一些隐藏文件就在那里时它不应该/不会真正打扰其他开发人员。
【讨论】:
【参考方案6】:我们签入 .project 和 .classpath。借助 ProjectSet,我们可以使用单个“导入团队项目集”检查复杂的工作区
【讨论】:
我们已经迁移到 maven。然后需要从存储库中删除这些文件。【参考方案7】:不签入 .project 文件会 使我的开发效率降低(我 不能简单地“导入”项目代码 从目录)
对于这个问题,您可以选择创建新项目并导入现有源代码。
IDE 特定文件(如 .project)的一个问题是其他开发人员可能想要使用另一个 IDE 来开发项目,因此他们可能会添加另一种类型的项目文件。这会让你的仓库变得混乱。
【讨论】:
... 这还将在类路径中包含正确的 jar,设置项目的编译器合规级别,并加载格式化程序和编译器警告配置? 或者您就使用哪个 IDE 达成一致,每个人都可以提高工作效率。【参考方案8】:我更喜欢签入 .project 和 .classpath。
当此项目由多个开发人员共享时,这将很有帮助。只需将其作为现有项目导入任何使用eclipse的系统。
这里需要注意的是类路径是相对于项目的。
【讨论】:
或仅使用类路径变量(例如 $TOMCAT_HOME)【参考方案9】:我经常有类似的、更笼统的问题。问题本质上是:
我要为我提交哪些文件? 我要为其他人提交哪些文件? → 如何结合“版本控制”的两个目标?我提议讨论这个there,因此您可以找到有关该问题的更多详细信息以及有趣的解决方案:)
我最喜欢使用git submodule
:将您的.project
文件等保存在一个私人提交存储库中。并将您最终的、纯粹的、必要的 src
产品制作成整洁的 submodule
nugget:公共回购。
project/ # root module
| .git # private repo
| .project
| .classpath
| momsNumber.txt
+---src/ # submodule
| | .git # public repo
| | main.java
| +---package/
| | | Etc.java
See there anyway.
【讨论】:
【参考方案10】:将 .classpath 和 .project 文件签入存储库没有问题。它将帮助使用 Eclipse 的开发人员更快地前进。
警告:确保您的 .classpath 文件仅引用与项目一起签入存储库或可以自动获取的工件(例如 maven 工件)。
【讨论】:
以上是关于Java 项目:应将 .classpath .project 文件提交到存储库中吗? [复制]的主要内容,如果未能解决你的问题,请参考以下文章
SpringBoot中classpath和classpath*