Hi Philipp, To add to the list of responses, I'd like to share the approach we use.
We develop an application rather small with ~50 bundles, based on Maven (+ bundle plugin, generated manifest) and git, with individual versioning. We mostly follow the one-bundle-one-repository approach, with a few exceptions where we have small maven-multi-module projects. To get the build together, we actually also ended up writing our own python based release tool that will interact with git and maven in a correct order. We found that the maven release plugin did not work well, especially because we don't want a new bundle version without an actual change. Moreover, we made that tool leverage our git-workflow and made it work with the Karaf-specific feature-xmls (e.g. removing -SNAPSHOT upon release). This brings me to the application level: an application is defined by its feature xml, the application version is completely determined by that, where indeed only a single bundle may have changed. The application build is also a single-version multi-module project containing distribution specific bundles, application wiring, application feature descriptor, Karaf distribution and integration test (with pax exam in the container just build before). We are mostly satisfied with that approach, although we had to put some effort into that python tool. However, we experience that, in particular when using semantic versioning, the Maven dependency approach and the at-runtime-OSGi dependency resolution are not very well compatible. If you don't want a consumer-breaking change to spread unnecessarily, you'd put them into multiple packages. But how to you split them across bundles? How do you update the bundle version? And then, maven's version resolution mechanism is rather dumb - it takes the closest/first dependency that is found. Stuff gets complicated there, because dependency declaration order plays a role. That's where changes spread across many repos and it starts to annoy. This is why we are looking into swapping over to Gradle + bnd + OBR, which looks like a winning combination to me. And as a last thing: Forget about git-submodules. I don’t know any (cleanly) working approach with that. Regards, Benjamin -----Original Message----- From: Gareth Collins [mailto:[email protected]] Sent: Donnerstag, 14. August 2014 02:47 To: [email protected] Subject: Re: OSGi and Git - what release process, how many repos? Hi Philip, I was in the same predicament as you. We have about ~100 bundles which we wanted to develop together but version separately (as various bundle subsets were also used in other projects). I originally started with svn using an external for each project...and I wanted the same structure for git (which meant repository per project). When migrating to git I discounted submodules because the "double-commit" felt too error prone and I wanted to be able to link a workspace to a "moving trunk" (like svn externals). I instead went with git slave. Unfortunately git slave had some limitations. It had some nice utilities but it assumes you want everything on the same branch/tag. It generates a .gitslave file with lines in this format: <relative remote url> <checkout directory> Eventually I gave up on gitslave and wrote my own multi-repository build script using gradle and jgit. I extended the .gitslave file format to be this: <relative remote url> <checkout directory> <branch or tag> <tag> where <branch or tag> - If a branch is specified here, I want a "moving trunk". If I have a tag here, it means I want to tie the workspace to a particular commit of this project (e.g. perhaps I have multiple workspaces which share a bndtools "cnf" which is based on a tag). <tag> - This is added and committed just before a release (via a gradle "preparerelease" task)...and removed and committed just after release (via a gradle "newdevelopment" task. This is added so I can create a reproducible release builds. I make every project include a version.properties file and use that as part of input to the relevant bnd file (which comes into play for semantic versioning), which will also be used to generate tags (which again I can do for all projects via a "tag" build target - "preparerelease" depends on that). The version.properties from each project is also used as input for building a karaf feature file. As part of my release build, I build the whole workspace with sematic version checking turned on. But as some bundles may not have had any changes since the last release, I added a check to only deploy to nexus if the bundle has not been deployed before. I only changed to this build approach recently so it still has some hairs on it (I was waiting for bndtools 2.3)...but it works for me so it definitely is possible to do. Anyway, hope this helps. thanks, Gareth On Tue, Aug 12, 2014 at 6:03 AM, Paul Bakker <[email protected]> wrote: > Hi Philipp, > > "Do I understand correctly, that your bundles have different > (semantic) version numbers, but are always tagged all at the same time?" > Yes, that's right. Our product version is the tag in Git on the whole > workspace that represents the set of bundles that gets deployed in > production. Internally we want to see which bundles are updated, and > how large (major/minor/micro) these changes are. > > It strongly depends on which development tooling you are using. When > using Bndtools there are definitely best practices, but they only > apply when using this tool. These best practices might be completely > different when using Maven for example. Before deciding on a > repository structure you should probably first decide on the tool > stack. Of course I would recommend Bndtools. > > Cheers, > > Paul > > > > > On Tue, Aug 12, 2014 at 11:48 AM, Bulu <[email protected]> wrote: > >> Hi Paul, hi all >> >> Do I understand correctly, that your bundles have different >> (semantic) version numbers, but are always tagged all at the same time? >> >> Regarding Git though, I'm still confused. >> Carsten Ziegler advocates the one repo - one bundle. Which certainly >> makes sense, for separate bundle release cycles. >> Mathilde even had to build an own building tool, I hope I can avoid >> that (maybe you want to check out the repo tool from google >> https://code.google.com/p/git-repo/ which is used by Android) And >> Paul Bakker has one repo for all bundles, all in one Eclipse workspace. >> >> So we have all possible combinations... >> I would love to here more experiences of other people doing OSGi on Git... >> >> Regards Philipp >> >> >> >> On 11.08.2014 15:21, Paul Bakker wrote: >> >>> 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 <[email protected]> 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: [email protected] >>>> For additional commands, e-mail: [email protected] >>>> >>>> >>>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
