felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Felix Meschberger <fmesc...@gmail.com>
Subject Re: OSGi core and compendium bundles
Date Sat, 16 May 2009 09:02:18 GMT

Alin Dreghiciu schrieb:
> A while ago I searched for a repository that contains the core and/or
> compendium jars but could not find one. So, at that moment I uploaded them
> to OPS4J repository:
> http://repository.ops4j.org/maven2/org/osgi/org.osgi.core/
> http://repository.ops4j.org/maven2/org/osgi/org.osgi.compendium/
> I guess that best will be to have them in Maven central repository and I
> recall posting a message on this list related to this subject as Peter K.
> told me that he does not know how to do so, so maybe someone from Felix
> could take that job.

The maven project has a description of the process to follow to upload
artifacts to central [1].

Alternatively, it might be conceivable, that we try to use the nexus
repository at repository.a.o to upload them on behalf of the OSGi. We
would have to ask infra@ on whether this would be an option.


On a side track: Have you considered syncing the ops4j release
repository with the cetral repository as described on the same page.


[1] http://maven.apache.org/guides/mini/guide-central-repository-upload.html

> On Fri, May 15, 2009 at 7:31 PM, Richard S. Hall <heavy@ungoverned.org>wrote:
>> For those not following the users@ discussion, here is a link:
>> http://www.nabble.com/-karaf--Equinox-integration-problem---and-possible-solution-to23559788.html
>> The above thread discusses an issue with using our compendium bundle. This
>> is not the first time this issue has been raised. The summary is our
>> compendium bundle results in odd class loading errors in some cases. My
>> conclusion is that this is because we dynamically import *, so dependent
>> bundles are using the compendium packages even though the compendium
>> dependencies are not actually satisfied.
>> We dynamically import * to avoid forcing all users of compendium to satisfy
>> all dependencies to use it, because most of the time they are not needed for
>> the contained service interfaces. However, in the cases where they are
>> needed, it is problematic.
>> Why do we provide these bundles at all? Originally, the OSGi JAR files were
>> not bundles, so we needed something and did it ourselves. Now this is no
>> longer the case, I believe.
>> It seems we need to figure out what we should do to address such issues in
>> the future. I think there are three options:
>>  1. Stop providing these bundles altogether and just rely on the
>>     official artifacts from the OSGi Alliance (I believe they are in a
>>     maven repo somewhere).
>>  2. Provide them with their full explicit dependencies (i.e., static
>>     Import-Package declarations).
>>  3. Divide them up into more reasonable chunks, since they lack
>>     cohesion as bundles which makes managing their dependencies more
>>     unreasonable (e.g., it sucks having to deploy a provider of
>>     javax.microedition.io for org.osgi.service.io when you just want
>>     to use logging).
>> At this point, I think the order of the options listed here is the order of
>> my preference.
>> I talked to Tom Watson about this and he agrees, saying he thinks their
>> bundles are a mistake and doesn't plan on updating them. His recommended
>> approach for the future is to bundle the API with the implementations.
>> Sounds good to me, since that's what we do too. What do you guys think?
>> -> richard

View raw message