Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
AW: [equinox-dev] Packaging opensource libraries as osgi bundles

Hi,

 

to package opensource a) libraries into bundles sounds good. It is encouraging bundle like developing. Which opensource libraries could canditates? All? e.g. like the Maven public repository? Maintaining a repository of opensource bundles can become expensive depend the amount of opensource libraries and those different release cycles. To adopt services for opensource libraries feels more difficult for me because you have to define contracts and interfaces whose have to fulfil all requirements and to maintaining the stuff if some requirement change. Opensource libraries have different APIs, different concepts how to use. Maybe for some libraries it is better to whose by classes directly.

 

Best Regards

Alexander

 


Von: equinox-dev-bounces@xxxxxxxxxxx [mailto:equinox-dev-bounces@xxxxxxxxxxx] Im Auftrag von Piero Campanelli
Gesendet: Don
nerstag, 9. November 2006 17:48
An: osgi-dev@xxxxxxxxxxxxxxxx; equinox-dev@xxxxxxxxxxx; felix-dev@xxxxxxxxxxxxxxxxxxxx
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 projects (starting from most used/trendy) would be packaged as osgi bundles and keeped them in a repository. ( bundles.osgi.org for example or any other). I see interesting the Eclipse Orbit initiative which is however devoted only to "eclipse-related" libraries.

Clearly the problem of maintaining this repository would be high but the 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 than traditional approach).

What do you think about that?

PS
As exercise I am starting porting existing opensource libraries as OSGi bundles. I think there are two level of adoption:
a) package "components" as osgi bundles and keep tracks of dependencies and versions
b) adopt a service oriented approach (using osgi registry or declarative service)

a) can be done easily and I think can also be maintained externally from the main trunk of the project (if project is well modularized). b) should be adopted from project team :)


Back to the top