yes it is ! On my current project I have some definitions like this :
* component. Each component covers a functionality of my project and
can be composed by several bundles (typically : one bundle for data
model and one bundle for UI). Each component has its own versioning
policy and so its own git repository. Each component version is a
git tag.
* distribution : this is the final application delivery. It is
composed by set of versioned component + the OSGI container (virgo
currently) + a python installer to help the configuration of the
application + some others things I forgot ;)
Currently I have a custom python tool to define the distribs (ie :
versions of components for each distrib) and build it from the
components git repositories...
You can have a look on that tool here :
https://github.com/echinopsii/net.echinopsii.ariane.community.distrib
At the time I wrote this distribution tool I didn't see any other tool
to help me manage and build project dispatched through many git
repositories. If you know any tool covering that need I'll be happy to
test it...
Mathilde
On 11/08/2014 13:29, Christian Schneider wrote:
Very good question. We have the same issue in Apache Aries and I think
it is a reason why aries is still on svn.
So a good solution for the problem of multiple modules with possibly
different version numbers on git is highly relevant.
Christian
Am 11.08.2014 12:25, schrieb Bulu:
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]
