OSGi and source code control

[Mads Stavang]

Hi,

I'm in the startup phase of a big software project, and we have more or less decided to use OSGi to handle our component based structure. I will probably use services instead of importing/exporting packages, but the general plan is the following bundle structure:

Bundle 1: Interface_A
Bundle 2: Interface_A Implementor_1
Bundle 3: Interface_A Implementor_2
Bundle 4: Component using Interface_A
Bundle 5: Another component using Interface_A
etc.

Going by this model, we would create a lot of bundles (I'm talking about at least 100), so source code management is going to be critical.

I have been using subversion with Eclipse for my previous project, which was one big monolithic project. This will be much more modular, but I'm not quite sure how to handle this. One way would be to create a svn project per bundle, tagging each bundle separately as they change. It sounds like a tough task to handle all the dependencies.
I also thought of using a DRCS like Git or Mercurial, but they propagate one repository per project (or in this case bundle), which sounds like quite an overhead. I still like to consider them, because branching and merging is such a pain in subversion.

Have any of you experience with this kind of project? Are there any books/webpages/blogs/whatever which could give me hints/tools on how to approach this problem?

[Ulf Dittmer]

Why do you want to separate the code into multiple projects? Obviously you'll have many build files in many subdirectories, but what benefit do you see in multiple projects? Just so each bundle's code is only tagged with exactly those tags that are relevant to that bundle? svn has no problems with lots of tags. As long as you name the tags so it's obvious to which bundle they belong you should be fine.

[Mads Stavang]

I have been so used having only type of tag to a project, that I could not imagine tracking several versioned modules under one project.

Hmm, lets say I work on a project with multiple modules under Eclipse/subversive. If module 1 depends on Interface A v1.0.0 and module 2 depends on Interface A v2.0.0, how would you handle this in Eclipse? I see the limitation in Eclipse being able to import only one version of the interface.

[Ulf Dittmer]

I'm not an Eclipse user, so I have to pass this question. Does that mean Eclipse does some special thing with version control?

[Mads Stavang]

Ulf Dittmer wrote:I'm not an Eclipse user, so I have to pass this question. Does that mean Eclipse does some special thing with version control?

You can link jars to a project, so that Eclipse can build the project automatically. Probably works like java -classpath, so we will have the same classpath problem if we link two jars containing the same classes but different versions, it picks the class from the first jar.

Edit:
I just realize linking jars to a project in eclipse is probably the wrong way to do it. I am after all going to use OSGi.