Managing team bundles

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:

1. Common bundles from projects such as Orbit or Apache that are managed by outside agencies.
2. Bundles that wrap domain specific jar files. We manage these bundles internally.
3. Bundles provided by other teams in the company that are effectively read only for us
4. 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.

---

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!

---

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.

---

It's better to use Apache Maven [1] if you like to use Eclipse-independent environment.

Pros:

• all your artifacts will be stored in one Maven repo. You can use such tools like Artifactory [2] to create and share Maven repo for whole team (to avoid any problems with 3rd-party artifacts)
• there a lot of OSGi Maven tutorials available that help you to find answers to almost all your questions
• Eclipse supports Maven very well with m2Eclipse [3] plugin
• IDE is not so important in this case. Your team members can select any (even vi or emacs)

Cons:

• you have to find Maven repos for all your artifacts. It's not so easy for Eclipse artifacts, but you can try to find them here: [4]
• change your project structure based on Maven requirements
• spend some time to understand and use Maven patterns (for OSGi)

[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

---

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.