[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Re: AW: [equinox-dev] Packaging opensource libraries as osgibundles
- From: "Mittag, Frank" <frank.mittag@xxxxxxx>
- Date: Mon, 13 Nov 2006 18:54:27 +0100
- Delivered-to: email@example.com
- Thread-index: AccE9/FrqZXHZDnDQBKArRM5gG7lNQCPeFUg
- Thread-topic: Re: AW: [equinox-dev] Packaging opensource libraries as osgibundles
I think having a central repository for bundles, containing bundled open source libraries as well as "real" OSGi bundles (with services) is a great thing. Actually I'm waiting for this since years. On the other hand we can learn a lot from the history of UDDI (and other registries/repositories) what does work and what does not work in terms of central repositories. UDDI started with the same idea of being THE one repository (or yellow pages) for all Webservices. They introduced great mechanisms to register, discover and maintain WebServices, but the 3 central UDDI repositories (IBM, Microsoft, SAP) were mainly used for testing purposes and simple WebServices. Now they are gone.
I see some reasons which would be valid to a OSGi repository too.
(1) Missing trust
If I want to use services (or bundles) for my business I want to be sure, that the functionality is reliable, stable, etc... How can I know whether the bundle provider is trustworthy or provides good quality? So there should be a mechanism to rate or certify bundles.
Bundles and services depend on conditions to run. These conditions may change over time. So how do I know whether the bundles are up-to-date or just outdated stuff (especially if they depend on other bundles). Imagine what happens if you put all versions of all Apache common projects into the bundle repository.
The first version of UDDI tried to be THE one repository. But every repository can be used in different contexts. E.g. a company could like to have an internal repository (non public) or we can image specialists, who only wants to provide a bundle repository for a specific topic. However, there is no problem as long as you can "attach" your repository content to the "big" repository. So UDDI v3 introduced such feature.
(4) Service and Support
Ok, I find the bundle I need, download it, try it and run into a problem. Where can I find documentation, a sample how to use it, an expert, a community? So any kind of help is welcome. There should be either a way to add this kind of info to the repository or have this help outside of the repository in some kind of OSGi development community (or both).
That should be enough for now :)
From: equinox-dev-bounces@xxxxxxxxxxx [mailto:equinox-dev-bounces@xxxxxxxxxxx] On Behalf Of Peter Kriens
Sent: Freitag, 10. November 2006 19:21
To: Neil Bartlett
Cc: Equinox development mailing lis
Subject: Re: AW: [equinox-dev] Packaging opensource libraries as osgibundles
I have made the OSGi Alliance board aware of the desire of an independent
repository. Any suggestions how the submit rules, retainment policies,
licensing issues, etc should be organized are welcome.
Is there a chance this would be THE bundle repository? Apache Felix is
also working hard on a repository that will be linked in OBR.
NB> Piero's original email did mention Orbit, and noted that it can only
NB> contain Eclipse-approved libraries. A more general repository would be
NB> very useful, as it could include libraries that Eclipse projects will
NB> never be allowed to use, eg the GPL-licensed ones etc.
NB> There's not necessarily much of a technical challenge here, it's more a
NB> problem of hosting costs. I think it would be a great thing for the OSGi
NB> Alliance to sponsor such an effort since it would ease the migration path
NB> for developers moving to OSGi.
NB> Even better would be if more open source projects could be convinced to
NB> offer bundle-ized distributions themselves. Again I think the Alliance
NB> might have a role to play.
NB> After all, what else have they got to spend those $20k/year membership
NB> fees on? ;-)
NB> - Neil
>> see the Orbit project
>> "Ziegler, Alexander " <Alexander.Ziegler@xxxxxxxxxxxx>
>> Sent by: equinox-dev-bounces@xxxxxxxxxxx
>> 11/10/2006 03:51 AM
>> Please respond to
>> Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
>> <pc@xxxxxxxxxxxxxxxxxxxx>, "Equinox development mailing list"
>> AW: [equinox-dev] Packaging opensource libraries as osgi bundles Hi,
>> to package opensource a) libraries into bundles sounds good. It is
NB> encouraging bundle like developing. Which opensource libraries could
NB> canditates? All? e.g. like the Maven public repository? Maintaining a
NB> repository of opensource bundles can become expensive depend the amount of
>> opensource libraries and those different release cycles. To adopt
>> for opensource libraries feels more difficult for me because you have to
NB> define contracts and interfaces whose have to fulfil all requirements and
>> to maintaining the stuff if some requirement change. Opensource
>> have different APIs, different concepts how to use. Maybe for some
NB> libraries it is better to whose by classes directly.
>> Best Regards
>> Von: equinox-dev-bounces@xxxxxxxxxxx
>> [mailto:equinox-dev-bounces@xxxxxxxxxxx] Im Auftrag von Piero Campanelli
NB> Gesendet: Donnerstag, 9. November 2006 17:48
>> An: osgi-dev@xxxxxxxxxxxxxxxx; equinox-dev@xxxxxxxxxxx;
>> Betreff: [equinox-dev] Packaging opensource libraries as osgi bundles Hi,
>> I am reflecting to the fact that it would be nice if a set of opensource
NB> projects (starting from most used/trendy) would be packaged as osgi
NB> bundles and keeped them in a repository. ( bundles.osgi.org for example or
>> any other). I see interesting the Eclipse Orbit initiative which is
NB> however devoted only to "eclipse-related" libraries.
>> Clearly the problem of maintaining this repository would be high but the
NB> benefits for osgi adoption could be interesting (specially when people see
>> that with osgi they are able to manage lot of lines code more easily
>> traditional approach).
>> What do you think about that?
>> As exercise I am starting porting existing opensource libraries as OSGi
NB> bundles. I think there are two level of adoption:
>> a) package "components" as osgi bundles and keep tracks of dependencies
NB> and versions
>> b) adopt a service oriented approach (using osgi registry or declarative
>> a) can be done easily and I think can also be maintained externally from
NB> the main trunk of the project (if project is well modularized). b) should
>> be adopted from project team :)
>> equinox-dev mailing list
>> equinox-dev mailing list
NB> equinox-dev mailing list
Peter Kriens Tel +33467542167
9C, Avenue St. Drézéry AOL,Yahoo: pkriens
34160 Beaulieu, France ICQ 255570717
Skype pkriens Fax +1 8153772599
equinox-dev mailing list