寻求共享 Eclipse 项目的建议
我正在寻找有关在开发人员之间共享 Eclipse 项目的最佳实践的建议。
在我看来，每个开发人员都应该有他/她自己的 Eclipse 工作区。然而，项目似乎更适合许多用户使用同一个项目，例如，如果多个用户正在处理某个特定组件，那么他们都可能需要使用该组件的项目，因为如果他们每个人都有自己的项目，他们每个人都必须设置和维护相同的项目依赖项等。看看这是否是其他人所做的，或者他们是否是为每个开发人员提供特定组件的自己的项目的原因。
另外，如果建议是共享项目，那么配置管理 Eclipse 项目的建议是什么？过去我们使用ClearCase，但现在我们希望改为Git 或SVN。在 ClearCase 世界中，频繁的签入和合并似乎是明智的做法，以帮助团队保持最新状态。再次，我正在寻找已经经历过这种情况的人们的意见。
感谢您的任何建议或外部“如何”书籍或网站！
谢谢，
肯
I'm looking for advice regarding best practices for sharing an Eclipse project among developers.
It seems clear to me that each developer should have his/her own Eclipse workspace. However, projects seem to loan themselves better for many users to use the same project, e.g., if several users are working on a particular component, they are all likely to need to use the component's project, since if they each had their own project, they'd each have to set up and maintain the same project dependencies, etc. Looking to see if this is what other folks do or if their are reasons to give each developer his own project for a particular component.
Also, if the recommendation is to share a project, what are recommendations for configuration managing an Eclipse project? In the past we have used ClearCase, but we are now looking to change to Git or SVN. In the ClearCase world, it would seem advisable to do frequent checkins and merges to help the team stay up to date. Again, I'm looking for opinions from folks who have already lived this.
Thanks for any recommendations or external "how to" books or websites!
Thanks,
Ken
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
共享 Eclipse 项目不会造成任何问题。只需将 .classpath、.project 文件和 .settings 目录（以及 Eclipse 在项目根目录生成的任何与项目相关的配置文件/目录）置于源代码管理之下。
另外，避免在项目中使用绝对路径（例如，对于外部库），因为所有开发人员不一定具有相同的设置并使用相同的位置。
Git、SVN 或 ClearCase：没关系：都允许共享 Eclipse 文件。
Sharing an Eclipse project doesn't cause any problem. Just put the .classpath, .project files and the .settings directory (and any project-related config file/directory that Eclipse generates at the root of the project) under source control.
Also, avoid using absolute paths in your project (for external libraries, for example), since all the developers don't necessarily have the same setup and use the same locations.
Git, SVN or ClearCase : it doesn't matter : all allow sharing Eclipse files.
我们将整个 Eclipse 项目文件夹置于版本控制之下（使用 svn:ignore 表示包含已编译类的目录）。
这使我们不仅可以共享构建配置，还可以共享启动配置（使用正确的虚拟机参数）、团队认为相关的编译器警告配置以及正在使用的编码约定的格式化程序配置。我们还可以通过这种方式设置文本文件编码。
We put the entire eclipse project folder under version control (with an svn:ignore for the directory containing the compiled classes).
This allows us to share not only the build configuration, but also launch configurations (with the proper VM-parameters), the configuration for compiler warnings the team considers relevant, and the formatter configuration for the coding conventions in use. We can also set text file encodings that way.
好点。
我们在 ClearCase 中遇到了一些问题。我们的第三方库被放置在版本控制下的文件系统的不同部分。因此，为了避免库的绝对路径，我们添加了一个 ant 脚本。该脚本会将库复制到直接位于项目根目录下的视图私有目录。
然后，我们向项目添加了一个构建器，以确保在每次清理+重建时首先运行脚本。
Good point.
We've had some issues with this in ClearCase. Our third party libs were placed in a different part of the filesystem under version control. So to avoid absolute paths to the libs we added an ant script. The script would copy the libs to a view private directory that was directly under the project root.
We then added a builder to the project to make sure that the script was run first at every clean + rebuild.