Central repository for OSGi bundles

[Marco Ehrentreich]

Hi,

I read in another post that there's currently no standard implementation of OSGi which supports kind of remote service for service bundles (although this is planned for future releases).

I'm wondering if there's a concept for "distributed OSGi" in general?!? Something like Maven repositories come to mind where OSGi boundles could be looked up, stored and retrieved by any OSGi runtime environment as needed. I hope you understand what I mean Wouldn't this be a good idea? Especially regarding the distributed nature of many complex applications today...

Marco

[Craig Walls]

Marco Ehrentreich wrote:I'm wondering if there's a concept for "distributed OSGi" in general?!? Something like Maven repositories come to mind where OSGi boundles could be looked up, stored and retrieved by any OSGi runtime environment as needed.

Distributed OSGi aside, the idea of a repository that houses bundles is such a good idea that it's been done...a lot!

The standard is OBR (OSGi Bundle Repository). It's been around for awhile and does a great job, but...there's a lot of work going on right now to tighten it up a bit so that it can work better going forward. Honestly, I've had only very small interaction with any OBR repositories, but I imagine that going forward OBR will be the best way to handle this kind of thing.

If you're using Pax Runner (or even have the Pax URL bundles installed), then you can use Maven repositories as bundle repositories. Using Pax URL (http://wiki.ops4j.org/display/paxurl/Pax+URL ...which Pax Runner uses under the covers to do this kind of thing), you can request a bundle out of a Maven repo using a URL like this: mvn:com.somegroupid/someartifact/1.0.0. For example, Pax Web 0.2.0 can be referenced with mvn:org.ops4j.pax.web.bundles/service/0.2.0.

In Pax Runner, that URL can be part of a provisioning file that Pax Runner uses at startup to load up bundles. If you have Pax URL installed in your OSGi runtime, you can do 'install mvn:org.ops4j.pax.web.bundles/service/0.2.0' in the OSGi runtime's console to install a bundle from Maven.

Note that most OSGi runtimes only support file: and http: URLs. Pax URL adds several new options to those frameworks, including mvn:, obr:, and ivy:. It also includes some handy URLs like wrap: for automagically wrapping a non-OSGi JAR file as a bundle on-the-fly (using BND).

[Craig Walls]

I forgot to mention that SpringSource manages a big bundle repository that they call the Enterprise Bundle Repository (http://www.springsource.com/products/dmserver/repository). Informally, you may hear people refer to it as BRITS (bundle repository in the sky). It's a Maven/Ivy repo that has nothing but OSGi bundles in it. And, it includes *many* popular open-source libraries that have been OSGi-ified for you, eliminating the need for you to convert/wrap them yourself.

As far as I know, BRITS isn't OBR-compliant yet, but there's a lot of buzz/pressure to do that.

[Marco Ehrentreich]

This OSGi thing gets really more and more interesting with every new information

Just from reading your explanation I'm wondering why OSGi isn't used for many more applications. Combined with Maven this seems like an excellent solution for maximum code reuse, automatic software updates, plugin mechanisms etc.

Thanks for this detailed answer!

Marco

[Craig Walls]

Marco Ehrentreich wrote:This OSGi thing gets really more and more interesting with every new information
Just from reading your explanation I'm wondering why OSGi isn't used for many more applications.

One has to wonder.

Combined with Maven this seems like an excellent solution for maximum code reuse, automatic software updates, plugin mechanisms etc.

Help me spread the word!

[Marco Ehrentreich]

Help me spread the word!

I'll do my very best

In fact I always loved similar features when working with the NetBeans platform, but of course a rich client platform is often a bit overkill just to have this functionality. OSGi seems to be perfect for this!

Marco

[Hong Anderson]

Marco Ehrentreich wrote:
Just from reading your explanation I'm wondering why OSGi isn't used for many more applications.

Actually, it's like do we really need it? Many things are interesting, but it's not like that they are the only ways to do what we want efficiently.
For example, if we don't deploy systems to production often, is it really need to put an effort breaking systems to separated modules that can be deployed independently? And server restart isn't that bad, it needs just couple of minutes to restart.

And if you're interested to use Spring-DM, don't forget that its license is GPL, if you don't be careful, you might be sued or be forced to open source code.

[Craig Walls]

Kengkaj Sathianpantarit wrote:
Actually, it's like do we really need it? Many things are interesting, but it's not like that they are the only ways to do what we want efficiently.
For example, if we don't deploy systems to production often, is it really need to put an effort breaking systems to separated modules that can be deployed independently? And server restart isn't that bad, it needs just couple of minutes to restart.

First, there's more to OSGi than fine-grained deployment...I just mentioned that piece because it fell into the conversation nicely.

Second, you speak of the "effort breaking systems to separated modules" as if that in itself is a bad thing or not worth the effort. If that's what you're saying, then I could not disagree more. Breaking systems into modules is a valuable practice (for reasons I've already given several times in this forum). And, I contend that the effort is minimal, especially once you get into the groove of doing it all the time. (In fact, now that I have a modular mindset, I struggle on projects that aren't modular already...modular design is just easier than non-modular design once you have experienced both.)

And if you're interested to use Spring-DM, don't forget that its license is GPL, if you don't be careful, you might be sued or be forced to open source code.

Let me stop you there...Spring-DM is covered under the Apache 2.0 license. SpringSource dm Server is GPL, but Spring-DM is a different thing and is Apache 2.0 licensed...just like the much of the rest of the Spring portfolio.

[Marco Ehrentreich]

For example, if we don't deploy systems to production often, is it really need to put an effort breaking systems to separated modules that can be deployed independently?

I have to disagree here, too. Sorry In my opinion breaking an application into separated "modules" should be as important with OSGi as well as without it! A module management system like OSGi (and maybe other similar concepts) just helps you to force yourself to think about application design and architecture harder.

As I wrote in others posts I had this experience with the NetBeans platform some time ago when I first was annoyed that it didn't allow me to package some parts of the application in a specific way or to declare dependencies between modules in another way. You could have forced the platform to accept circular dependencies etc. But instead I took the time and refactored and rearranged things to "conform" to the module system. In the end I realized that the problem wasn't in the module system but instead it was the bad architecture of my application. Having solved this initial problem by breaking things into reasonable modules helped me to maintain and extend this application easily later because the design was definitely cleaner and better than it would have been without those modules.

So in my opinion it's definitely worth the effort for any non-trivial application even without having the additional advantages of an OSGi environment!

Marco

[Hong Anderson]

Craig Walls wrote:

Kengkaj Sathianpantarit wrote:
Actually, it's like do we really need it? Many things are interesting, but it's not like that they are the only ways to do what we want efficiently.
For example, if we don't deploy systems to production often, is it really need to put an effort breaking systems to separated modules that can be deployed independently? And server restart isn't that bad, it needs just couple of minutes to restart.

First, there's more to OSGi than fine-grained deployment...I just mentioned that piece because it fell into the conversation nicely.

I know, and I just countered that point for the same reason as you .

Craig Walls wrote:
Second, you speak of the "effort breaking systems to separated modules" as if that in itself is a bad thing or not worth the effort. If that's what you're saying, then I could not disagree more. Breaking systems into modules is a valuable practice (for reasons I've already given several times in this forum).

Please read my sentence, don't just part of it. I think you missed the part "that can be deployed independently". It's totally different.

Craig Walls wrote:

And if you're interested to use Spring-DM, don't forget that its license is GPL, if you don't be careful, you might be sued or be forced to open source code.

Let me stop you there...Spring-DM is covered under the Apache 2.0 license. SpringSource dm Server is GPL, but Spring-DM is a different thing and is Apache 2.0 licensed...just like the much of the rest of the Spring portfolio.

Thanks for correction. I misunderstood.

[Hong Anderson]

Marco Ehrentreich wrote:

For example, if we don't deploy systems to production often, is it really need to put an effort breaking systems to separated modules that can be deployed independently?

I have to disagree here, too.

If you read the part "can be deployed independently" again, you might agree with me .

[Marco Ehrentreich]

If you read the part "can be deployed independently" again, you might agree with me .

Yes, yes... I agree It just sounded like you would see deployment issues as the only good reason for modularization...

[Ivano Pagano]

Kengkaj Sathianpantarit wrote:

Craig Walls wrote:
Second, you speak of the "effort breaking systems to separated modules" as if that in itself is a bad thing or not worth the effort. If that's what you're saying, then I could not disagree more. Breaking systems into modules is a valuable practice (for reasons I've already given several times in this forum).

Please read my sentence, don't just part of it. I think you missed the part "that can be deployed independently". It's totally different.

Hello Kengkaj,
I'd like to point out to you that designing applications to be modular and bundled for independent deployement, is so important and desired nowadays that projects like OSGi, Javaspaces, SOA in general are so much promoted and developed. Same reasons for the JCP that implements modular Java bundling and deployment!

I guess that we all agree that such solution can be burdensome for very small applications. But in the enterprise development scenario I could say that such a design approach can be more than helpful once you get accustomed to it, for every project you put your hands on.

It's like saying that IDEs can be burdensome, so that for small projects you only need your text editor (VI fans could shoot me now, all right! ). I simply don't agree.
You could always stick to your development model because you're very fast and experienced with it, but my opinion is that in the long run you'll lose lots of important improvements.
The last sentence was not aimed at anyone in particular, but I think that it gets to the point.

[Hong Anderson]

Marco Ehrentreich wrote:

If you read the part "can be deployed independently" again, you might agree with me .

Yes, yes... I agree It just sounded like you would see deployment issues as the only good reason for modularization...

Well, that is just a counter argument for a single point. And modularization and OGSi are not exactly the same thing.

I raised that because you asked like why many people don't use OSGi. For me it's depends on many things like infrastructure, working environment, resources, priorities, etc., not just oh it's good, why don't you use it?

And to be clarify, I didn't mean that OGSi is not good, I know the benefits of using it, I just expressed my opinion that why in some cases it's not necessary to use OSGi.

[Marco Ehrentreich]

I raised that because you asked like why many people don't use OSGi. For me it's depends on many things like infrastructure, working environment, resources, priorities, etc., not just oh it's good, why don't you use it?

I know that it "depends". Actually most things in software development depend... But please don't get wrong here. I don't think everyone should use OSGi or similar in any situation just because it's cool or sexy. It's just that in my opinion a lot more people SHOULD use OSGi (or maybe any comparable technology) just to force them to think about good application design and architecture principles. Unfortunately i think those people who don't care about "good" applications at all are the same people who don't know OSGi.

In the past I haven't used OSGi for any real world application myself. But after talking about some details here, I clearly see the advantages for almost any non-trivial application you can get with little additional effort. If you only start with the basics it wouldn't mean a big overhead to use OSGi if you care about a modular architecture anyway. That's the reason I raised my question why not more people use OSGi.

Marco