使 Eclipse 项目依赖项与外部构建系统保持同步

发布于 2025-01-02 08:37:07 字数 510 浏览 1 评论 0原文

情况是这样的。一个开发团队拥有大量(数百个)Eclipse 项目。代码非常混乱——正在创建新项目;项目正在被重命名,项目依赖关系也在不断变化。外部构建系统是ant。事实证明,保持 ant 构建文件中定义的依赖关系与 Eclipse 中的世界状态保持同步非常具有挑战性。外部 Ant 构建需要不断变化才能跟上。由于各种原因,使用 ant 作为 Eclipse 中的默认构建器并不是一种选择。开发人员希望继续使用 Eclipse 作为本地使用的构建和编辑环境。

问题:是否有一个工具可以允许维护一组依赖项,可供 Eclipse 以及像 ant 这样的外部构建系统使用? 我听说过 Gradle,但之前从未使用过它。在这种情况下这有意义吗?我很确定 Maven 无法满足需要的需求 典型的工作流程应该是:
1. 开发人员继续像现在一样工作 - 随意创建和更改 Eclipse 项目依赖项,并使用默认的 Eclipse 构建器在本地编译和测试。
2. 存在某种机制,可以将这些依赖项带入外部构建系统(如 ant),并在每次签入时触发外部连续构建。
感谢您的反馈 - 谢谢!

Here is the situation. A development team has a large number (hundreds) of Eclipse projects. The code is very much in churn - new projects are being created; projects are being renamed and project dependencies are constantly changing. The external build system is ant. It is proving extremely challenging to keep the dependencies defined in the ant build files in sync with the state of the world in Eclipse. The external ant build needs constant changes to keep up. For various reasons, using ant as the default builder in Eclipse is not an option. The developers want to continue using Eclipse as the build and edit environment for local use.

Question: Is there a tool which will allow a single set of dependencies to be maintained which can be used by Eclipse as well as an external build system like ant?
I have heard of Gradle but never used it before. Would it make sense in this context? I am pretty sure Maven wouldnt work for what is needed
The typical workflow should be:
1. Developers continue working as they currently do - creating and changing Eclipse project dependencies at will and using the default Eclipse builder to compile and test locally.
2. Some mechanism exists by which these dependencies can be carried into an external build system like ant and an external continuous build triggered on every checkin.
Appreciate your feedback - thanks!

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

少女情怀诗 2025-01-09 08:37:07

我们非常成功地使用 Gradle 解决了类似的问题。以下是设置概要

  • 每个项目都包含一个 build.gradle ,它定义了项目特定的依赖项和任务(甚至可能为空)。
  • 特殊的 master 项目包含 build.gradle,它为子项目设置常见的依赖项和任务,和/或注入与一组子项目相关的设置。
    • 逻辑上,master 项目是项目,但它作为同级文件夹存在,以便 Eclipse 可以更轻松地使用它。
  • Gradle 包含一个内置的 Eclipse 插件,该插件允许根据依赖项信息(包括项目间依赖项)为每个项目生成 Eclipse 设置文件。它非常适合简单的项目,而对于更复杂的项目,Gradle 允许您修改设置文件,因此您几乎可以完成所有操作。从这里您有两个选择:
    • 不要将 Eclipse 设置文件存储在存储库中,并在每次重新签出时调用生成任务(我更喜欢此选项)。
    • 告诉 Gradle 使用自定义变量来生成可以签入存储库的通用设置文件。然后,您只需在依赖项或其他配置发生更改时运行生成任务。
  • (可选)这有点棘手,但您可以让 Gradle 解析现有项目 ivy.xml 文件并从那里设置依赖项。我在这方面取得了一些成功,尽管我建议将依赖项转换为 Gradle 格式以获得更大的灵活性。
  • 持续构建系统与 Gradle 集成得很好(与 ant 相同)。如果您使用 Jenkins (Hudson),则有一个 Gradle 插件。

使用 Gradle 的优点是它的扩展性非常好,并且您可以同时支持其他 IDE,如 IntelliJ 或 Netbeans,而不需要付出太多努力(除非您有很多疯狂的自定义设置)。 Gradle 的优点和缺点是它是一个强大的构建系统,需要学习 Groovy 和 Gradle DSL,这可能需要一些时间才能掌握。文档也很棒。

Gradle 有一个非常活跃的社区,其唯一目的就是解决此类问题。

希望这会有所帮助,祝你好运!

We have been quite successful at using Gradle to tackle a similar problem. Here's the outline of the setup

  • Each project contains a build.gradle that defines project specific dependencies and tasks (may even be empty).
  • A special master project contains build.gradle that sets up common dependencies and tasks for child projects, and/or injects settings pertinent to a group of child projects.
    • Logically master project is the parent project, but it exists as a sibling folder so that Eclipse can be more comfortable with it.
  • Gradle contains a built-in Eclipse plugin which allows generation of Eclipse settings files for each of the projects from the dependencies information (including inter-project dependencies). It works nicely for simple projects, and as for more complicated ones Gradle allows you to tinker with the settings files, so you can do pretty much everything. From here you have two options:
    • Not to store Eclipse settings file in the repository and call the generation task every time you do a fresh check-out (I prefer this option).
    • Tell Gradle to use custom variables to make it generate generic settings files which can be checked-in to the repository. You'll then only need to run the generation task when dependencies or other configuration changes.
  • (Optional) It's a little tricky, but you can make Gradle parse existing project ivy.xml files and set up dependencies from there. I had some success with this, although I would recommend converting dependencies into Gradle format for more flexibility.
  • Continuous build system integrate with Gradle very well (same as ant). If you are using Jenkins (Hudson) there is a Gradle plugin.

The advantage of using Gradle is that it scales pretty well, and you can support other IDEs like IntelliJ or Netbeans at the same time without much effort (unless you have lots of crazy custom settings). An advantage and a disadvantage is that Gradle is a powerful build system which requires learning Groovy and Gradle DSL which may take some time to acquire. Also the documentation is awesome.

Gradle has a very active community with the sole purpose of tackling exactly this kind of problem.

Hope this helps, and best of luck!

淡淡離愁欲言轉身 2025-01-09 08:37:07

如何解析 .classpath 文件、生成依赖关系树并从根开始构建。您需要的是项目布局的约定或通用(ant-)构建文件,如果需要,可以在每个项目中更改该文件(例如不同的项目布局)。我不确定 Eclipse Tycho 是否可以用于此目的,因为它是一个用于构建 Eclipse 插件或项目的 Maven 插件。但它能够解决捆绑包和项目对 Maven 存储库和 Eclipse 更新站点的依赖关系。

How about parsing the .classpath files, generate a dependency tree and start building from the root. What you need is a convention on the layout of your projects or an generic (ant-) buildfile that could be changed in each project, if needed (e.g. different project layouts). I´m not sure if Eclipse Tycho could be used for that, since it´s a maven plugin(s) to build eclipse plugins or projects. But it´s able to resolve the bundle and project dependencies against maven repositories and eclipse update sites.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文