管理团队捆绑包
我们正在将我们的应用程序转移到 OSGI 平台（所有开发人员都使用 Eclipse），并试图找出开发我们的捆绑包的最佳团队环境。
我们有来自多个来源的捆绑包：
- 来自由外部机构管理的 Orbit 或 Apache 等项目的常见捆绑包。
- 包装特定于域的 jar 文件的捆绑包。我们在内部管理这些捆绑包。
- 公司其他团队提供的捆绑包对我们来说实际上是只读的。
- 我们团队提供的包含积极开发的源代码的捆绑包。
在情况 1-3 中，我们希望安装在本地 Eclipse IDE 中并提供目标平台。在我看来，我们只需创建一个 p2 存储库，它提供 1-3 中的所有捆绑包，并将它们作为目标定义提供。如果有更好的解决方案，请随时指出。
案例 4 中包含的包存储在 Mercurial 存储库中。尽管目标定义看起来可以从多个源获取捆绑包，但它没有解决如何包含来自 (d)vcs 的捆绑包。
最佳实践是什么？我们是否将 (d)vcs 捆绑包信息放入目标平台中，然后让开发人员手动下载正确的捆绑包？另外，我们如何管理目标定义的更改？当它发生变化时，我们是否必须向每个人发送电子邮件，或者是否有更优雅的解决方案？
感谢您的帮助。
We are moving our application to the OSGI platform (All developers are using Eclipse) and are trying to figure out the best team environment for developing our bundles.
We have bundles from multiple sources:
- Common bundles from projects such as Orbit or Apache that are managed by outside agencies.
- Bundles that wrap domain specific jar files. We manage these bundles internally.
- Bundles provided by other teams in the company that are effectively read only for us
- Bundles provided by our team that contain actively developed source code.
In cases 1-3 we would like install in our local Eclipse IDE and provide a target platform. It seems to me we would just create a p2 repository that provides all of the bundles in 1-3 and provide them as a target definition. Feel free to point out a better solution if there is one.
The bundles contained in case 4 are stored in a Mercurial repository. Although the target definition looks like it can grab bundles from several sources it does not address how to include bundles from a (d)vcs.
What is the best practice? Do we put our (d)vcs bundle information in the target platform and just make developers download the correct bundles manually? Also how do we manage changes to the target definition? Do we have to email everyone when it changes, or is there a more elegant solution?
Thanks for your help.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
与开发人员共享目标的空间。缺点是，我们的 SVN 中有工件！
但 p2 存储库听起来要好得多。当每个开发者激活自动更新时，他会通知何时有可用更新。
我想我们将来必须在我的公司尝试一下。
我们通过团队项目集 (*.psf) 共享我们积极开发的源代码。这是一个单一的文本文件，其中包含导出 Eclipse 项目的所有存储库信息。在 Eclipse IDE 中尝试使用
File ->;导出->团队->团队项目集。项目集是否有任何更改，实际上我们会向开发人员发送电子邮件。我认为更优雅的方式是通过 p2 存储库共享它。我希望这对我有帮助，并对我的英语不好表示歉意！
space to share the target to the developer. The disadvantage is, that we have artifacts in our SVN!
But the p2 repository sounds much better. When every devloper activate auto-update, he will informed when updates avaiable.
I think we must try it in the future at my company.
Our actively developed source code we share by Team Project Sets (*.psf). This is an single text file which contains all repository information of the exportet eclipse projects. Try it in your Eclipse IDE with
File -> Export -> Team -> Team Project Set. Are there any changes on the Project Set actually we send an email to our developers. An more elegant way I think is it to share it over the p2 repository.I hope that helps and sorry for my bad english!
我正在使用 eclipse、m2eclipse、 maven-bundle-plugin< /a>、颠覆、nexus 和 hudson，它很有魅力，尤其是在团队环境中。
自动生成manifest.mf 在 OSGi 中至关重要，因为手动执行此操作非常容易出错。使用 bnd （由 bndtools 或 maven-bundle-plugin)
Pax Construct可以帮助构建一个完整的OSGi运行环境。
I am using eclipse, m2eclipse, maven-bundle-plugin, subversion, nexus and hudson, and it works like a charm, especially in a team environment.
Automating the manifest.mf generation is critical in OSGi, because doing this by hand is very error-prone. Use bnd for this (automated by bndtools or maven-bundle-plugin)
Pax Construct can help in building a complete OSGi runtime environment.
如果您喜欢使用独立于 Eclipse 的环境，最好使用 Apache Maven [1]。
优点：
缺点：
[1] - http://maven.apache.org/
[2] - http://www.jfrog.org/products.php
[3] - http://m2eclipse.sonatype.org/
[4] - http ://build.eclipse.org/helios/hybrid/final/
问候，
德米特罗
It's better to use Apache Maven [1] if you like to use Eclipse-independent environment.
Pros:
Cons:
[1] - http://maven.apache.org/
[2] - http://www.jfrog.org/products.php
[3] - http://m2eclipse.sonatype.org/
[4] - http://build.eclipse.org/helios/hybrid/final/
Regards,
Dmytro
感谢所有回答的人深入了解其他人如何解决这个问题。
我们最终选择了 Buckminster。它使我们能够快速描述所有捆绑包的位置（案例 1-3 来自 p2 存储库，案例 4 来自 Mercurial），并通过 CQuery 一键设置空工作区。与我在其他项目中使用的 PDE 构建相比，它还与 Hudson 集成良好，并简化了 CI 设置。
Thanks to everyone who answered for the insight into how others are solving this problem.
We ended up going with Buckminster. It allows us to quickly describe where all our bundles are (cases 1-3 from p2 repositories, case 4 from mercurial) and provides one click setup of empty workspaces through the CQuery. It also integrates well with Hudson and simplifies CI setup compared to the PDE build I have used on other projects.