On 12/08/14 11: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...
This is a thing that many developers seem to mix up.
Source code version control and developing the actual code are different
concerns and actually orthogonal to each other.
So, if you follow the correct OSGi procedures - mainly semantic
versioning - then it really doesn't matter how you organise your code in
your version control system; anything that works for you is fine.
You can gear towards easy deployments, easy development, product
cohesion, whatever you like.
I do suggest that you start using bundle repositories though, since that
will make it even less relevant how everything is organised in your
version control system.
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]
--
Ferry Huberts
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
