Hi Bulu, All our projects are based on Bndtools. This is by far the best development environment for OSGi and I strongly advise taking a look at it. We build using Gradle, which is supported directly in bnd.
All bundles that belong to the same "product" are in the same Bndtools/Eclipse workspace, and the same GIT repo. Separating this even further makes development much harder and doesn't really have any benefits. The set of bundles that are part of a deployment are defined in a bnd "run configuration". When creating a release of the product we set a tag in GIT and run a build from this tag. The delivery from the build are the JARs defined in the run configuration. To give an indication, our larger projects might have ~200 bundles from a single workspace. As long as you adhere to modularity rules when it comes to bundle and service design it doesn't really mater if these bundles come from the same development workspace. In our projects we also use baselining; each bundle is versioned individually using the semantic versioning rules. Baselining means that the build checks if the bundle version (and export package versions) are still correct. This means that although we always tag our complete product version in GIT, it might mean that a new product release only contains a single updated bundle. Our release process is entirely automated, all the way from setting the tag to deploying to production servers and is used on several large projects. Cheers, Paul On Mon, Aug 11, 2014 at 12:25 PM, Bulu <b...@romandie.com> wrote: > Hi all > > I'm new to Git and want to use it for my new OSGi project. The project > will be split in some ~20 bundles which are intended to work together and > form a single shippable product with a unique release version number. > Nonetheless, at a later time, some of these bundles might be used outside > of that product in separate projects. > > I would like to have your experience what works and what doesn't. (links & > readings also welcome) > > First purely OSGi: the full product version 1.0 is comprised of bundles > each of which has a different version number in itself. Where do you store > that information? Does each bundle get to know that it is part of a parent > release 1.0? Is Maven the (only? best?) way to go? > The bundles will still be tightly coupled - eg. change the API, change the > impl, change all consumers. So is the "typical" release process to have all > bundles in -SNAPSHOT and only change that to a valid version when a release > is getting prepared? > > Now I want to use git for this. Do you recommend having > 1. one repo per bundle (what tools to use for managing that many repos?) > 2. one branch per bundle in a single repo > 3. use git submodules > 4. other approaches? > > My "main-line" will probably be latest&greatest of all bundles. I will > want to run integration tests which assembles the fully working product and > then runs the tests. Are there any advantages or disadvatages to any of the > approaches above (eg. for the continuous integration, building from sources > etc)? > > Thanks for your answers. > Philipp > > PS: I understand my question is not specifically linked to Felix > (although, that's what I use). If you consider this too much off-topic, > please recommend another forum. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@felix.apache.org > For additional commands, e-mail: users-h...@felix.apache.org > >
