如何在运行时确定 Mavenized Eclipse 项目目录的路径答案

【问题标题】：How to determine at runtime the path to a Mavenized Eclipse project directory如何在运行时确定 Mavenized Eclipse 项目目录的路径
【发布时间】：2009-11-17 15:40:28
【问题描述】：

完全是 Maven 新手，正在尝试（与一个相当大的团队的其他成员一起）将一大堆遗留代码从 ant 转换为 Maven。它工作得相当好，但我遇到了以下问题。

我有一个项目，我们称之为Core，运行时需要加载一些不同项目下签入的文件，我们称之为资源A和B。Core代码是在某个工作目录下启动的，我们称之为core/runtime，它读取一个属性文件以确定从资源 A 和 B 加载什么，并附上相关资源的相对路径，例如

  resource.ham=../../resources-a/files/ham.rsrc
  resource.eggs=../../resources-b/files/eggs.rsrc

（是的，我知道这是病态和错误的，我们应该通过类加载器从 JAR 加载资源作为资源，也许是某种容器或依赖注入器或其他。不是我的想法，不是我当前的问题，不是现在要解决的问题。）

（说真的，请不要费心建议我们解决根本问题。我们知道我们需要解决根本问题。我们知道我们需要解决根本问题问题在我们切换到 Maven 之前，在我们切换到 Maven 之前，愚蠢的 hack确实有效。我知道这会让你感觉很好，但它没有帮助 b>。这是一个有 10 年历史的代码库，包含数万个类，相信我，它还有很多更重要的问题。）

这种相对路径破解只是 Eclipse 中的一个问题，在开发过程中；在实际部署的应用程序中，文件位于完全不同的地方，并且以更合理的方式加载。

无论如何，当这些是普通的 Eclipse 项目时，这一切都很好，所以有问题的目录具有如下路径：

  c:\workspace\core\runtime
  c:\workspace\resources-a\files
  c:\workspace\resources-b\files

但是，现在这些已作为 Maven 项目签出，目录现在类似于：

  c:\workspace\core\runtime # Inexplicably unchanged
  c:\workspace\maven.8675309\resources-a\files
  c:\workspace\maven.6345789\resources-b\files

问题：

我可以让这些maven.7762323 目录消失吗？
如果没有，Eclipse 中是否有某种方法可以获取项目目录的路径，然后在启动配置中将其作为系统属性传递，或者类似的方式？

任何解决方案都必须是我可以签入 SVN 的解决方案，以便我团队中的其他开发人员可以开箱即用地使用它。

更新

好的，我知道maven.[number] 目录的来源：当您在 SVN 存储库中选择父目录并说“签出为 Maven 项目”时，您会得到一个与父目录对应的maven.[number] 目录，其中所有实际项目作为子目录。如果代码实际上都在同一个父目录中，甚至在同一个SVN存储库中，那将非常方便。

【问题讨论】：

您能否阐明您的目标或预期的布局？如果 m2eclipse 对任何烦恼负责，为什么不在命令行上使用 svn 进行结帐？我一定是错过了什么。

标签： java eclipse maven-2

【解决方案1】：

我可以让这些 maven.7762323 目录消失吗？

~~他们来自哪里？ 作为 Maven 项目签出到底是什么意思？~~

（编辑：正如 OP 在评论中所写，这些目录来自 m2eclipse，允许从 SVN 签出 maven 项目。我不使用此功能，所以我不太了解它。但是，经过一番谷歌搜索，我的理解是这些名称是临时的，m2eclipse 应该在结帐结束时重命名它们。也许结帐期间 eclipse 出了点问题。我不确定。）

如果没有，Eclipse 中是否有某种方法可以获取项目目录的路径，然后在启动配置中将其作为系统属性传递，或者类似的方式？

Eclipse 有一个{build_project} 变量，可以在运行时配置的参数中使用。也许{workpsace_loc} 更适合您的情况。整个列表在运行时配置的 Arguments 选项卡中提供了描述。

（编辑：我仍然不确定我是否达到了真正的目标，但我觉得使用 svn:externals 会有所帮助。）

【讨论】：

m2Eclipse 在 SVN 存储库视图中提供了“签出为 Maven 项目”选项。我不确定这一切的作用，但我怀疑它会创建可识别 Maven 的 .classpath 和 .project 文件（如果这些文件尚不存在）。
在实际部署中，没有相对路径黑客 b/c 有问题的文件最终位于 core/runtime 下的子目录中。其中包括例如用户在部署后编辑的配置文件。这些资源都是可选的，单独构建，通过解压各种 zip 文件进行部署。这是我继承的一团糟，计划是用 OSGi 之类的东西取代本土的垃圾，但在接下来的两个月里，这不在桌面上，我们有一个版本可以从现在到那个时候发布。

【解决方案2】：

好的，解决方案是使用{workspace_loc:项目名称} 变量将少数项目目录设置为系统属性，并使用它们来推断其他所有内容。现在，如果我能弄清楚如何让加载插件 JAR 的荒谬系统与 Maven 一起工作......

【讨论】：