Not sure if that would be what you are asking for, but I have written a small Gradle plugin that builds and runs OSGi environments by picking up bundles from the configured repositories (can be Maven, Ivy or even file repositories, all the ones supported by Gradle) or Gradle sub-projects. It's quite simple: if you publish all your bundles to a repository, you can then just given their coordinates in your build.gradle file and this plugin will create an OSGi environment that can then be started by using either Felix or Equinox (you can use others as well if you provide some configuration). All you have to do is: gradle createOsgiRuntime or gradle runOsgi You could use other Gradle plugins to publish all artifacts collected with "createOsgiRuntime" to your repository (I would probably just write little Groovy script to do that - but I am comfortable with the Gradle API, if you're not it may be a little tricky). Here's a link to the plugin: https://github.com/renatoathaydes/osgi-run There's many examples on how you can use it in the tests folder: https://github.com/renatoathaydes/osgi-run/tree/master/osgi-run-test Version 1.0 is very crude still, but I am hoping to release 1.1 soon which will be much nicer. Would that be helpful to you? Regards, Renato
> Date: Wed, 20 Aug 2014 14:15:27 +0200 > From: [email protected] > To: [email protected] > Subject: Re: OSGi and Git - what release process, how many repos? > > Thanks to all for sharing your workflows. > > I think the main conclusion is, that there is still a gap here - most > respondents either have had to build their own release/commit tool or > are working all in one repo. > Given the ubiquity of git and OSGi, I would argue that having a tool to > manage the release of a group of OSGi bundles, each of which is in a > separate git repos, in a generic form would be a big benefit. > > Are there any existing efforts in this direction? > > Regards > Philipp > > > > On 20.08.2014 01:12, Dragos Dascalita Haut wrote: > > In a similar way I've been using for more than 1 year git-subtree. Mostly > > Jenkins cares about it. > > > > All my bundles are "symbolic linked " with git-subtree into a single git > > repository and developers only care about 1 repo. > > > > Each bundle has its own repo too, which is used when performing releases. > > > > When happy hour for release comes Jenkins gets the latest code from the > > subtree, pushes it into the particular git repo of that bundle, performs > > the maven release, versions are increased and at the end Jenkins pulls the > > new pom file into the main git repository. > > > > > > HTH, > > Dragos Dascalita Haut > > > > Sent from my iPhone > > > >> On Aug 19, 2014, at 12:04 PM, Cristiano Gavião <[email protected]> wrote: > >> > >> Hi, > >> Currently I'm with Carsten, after suffering trying to release bundles with > >> different version in same git repository. > >> For new project I decided to go with this path: one bundle (or more than > >> one if they are enough tight to share same version) per git repository. > >> > >> In addition we created a special repository containing the corporate pom > >> and scripts (with a file listing existing repositories) that can clone, > >> pull, etc all repositories together... > >> > >> and this way we can release every bundle separately using > >> maven-release-plugin and a tagged version is just for this bundle, avoid > >> confusing when need to back to an old version or need to work with more > >> than one version at same time (multi-tenant). > >> > >> regards, > >> > >> Cristiano > >>> On 12-08-2014 06:48, Bulu 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] > >> > > --------------------------------------------------------------------- > > 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] >
