Reputation: 3994
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:
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.
Upvotes: 2
Views: 442
Reputation: 3994
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.
Upvotes: 1
Reputation: 389
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.
Upvotes: 2
Reputation: 2369
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
Upvotes: 1
Reputation: 2831
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!
Upvotes: 2