You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by "Richard S. Hall" <he...@ungoverned.org> on 2009/05/15 18:31:13 UTC
OSGi core and compendium bundles
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
Re: OSGi core and compendium bundles
Posted by Guillaume Nodet <gn...@gmail.com>.
Imho, we should provide the spec package along with the implementation
for each service we provide and not support the org.osgi.compendium
one.
On Fri, May 15, 2009 at 18:31, Richard S. Hall <he...@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
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: OSGi core and compendium bundles
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
Alin Dreghiciu schrieb:
> FYI
>
> 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.
WDYT ?
On a side track: Have you considered syncing the ops4j release
repository with the cetral repository as described on the same page.
Regards
Felix
[1] http://maven.apache.org/guides/mini/guide-central-repository-upload.html
>
> On Fri, May 15, 2009 at 7:31 PM, Richard S. Hall <he...@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
>>
>
>
>
Re: OSGi core and compendium bundles
Posted by Alin Dreghiciu <ad...@gmail.com>.
FYI
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.
On Fri, May 15, 2009 at 7:31 PM, Richard S. Hall <he...@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
>
--
Alin Dreghiciu
Software Developer - Looking for new projects!
My profile: http://www.linkedin.com/in/alindreghiciu
My blog: http://adreghiciu.blogspot.com
http://www.ops4j.org - New Energy for OSS Communities - Open Participation
Software.
http://www.qi4j.org - New Energy for Java - Domain Driven Development.
Re: OSGi core and compendium bundles
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
Filippo Diotalevi schrieb:
> On Fri, May 15, 2009 at 8:04 PM, Felix Meschberger <fm...@gmail.com> wrote:
>> Richard S. Hall schrieb:
> [...]
>>>>> 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).
> [...]
>> Ok, then I am also in favor of dropping it.
>
> Just a question, though: what exactly do you mean by "stop providing"
> and "dropping"?
>
> If you suggest to delete them from the trunk I'm fine with that, but I
> hope the released version will stay in the Maven repository, otherwise
> all my maven builds will break!
Yes, that's what we mean: We stop releasing our own bundles.
Artifacts already deployed are not removed, of course.
Regards
Felix
Re: OSGi core and compendium bundles
Posted by Filippo Diotalevi <fi...@gmail.com>.
On Fri, May 15, 2009 at 8:04 PM, Felix Meschberger <fm...@gmail.com> wrote:
> Richard S. Hall schrieb:
[...]
>>>> 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).
[...]
> Ok, then I am also in favor of dropping it.
Just a question, though: what exactly do you mean by "stop providing"
and "dropping"?
If you suggest to delete them from the trunk I'm fine with that, but I
hope the released version will stay in the Maven repository, otherwise
all my maven builds will break!
--
Filippo Diotalevi
Re: OSGi core and compendium bundles
Posted by Karl Pauls <ka...@gmail.com>.
me too.
regards,
Karl
On Fri, May 15, 2009 at 8:04 PM, Felix Meschberger <fm...@gmail.com> wrote:
> Hi,
>
> Richard S. Hall schrieb:
>> On 5/15/09 1:50 PM, Felix Meschberger wrote:
>>> Hi,
>>>
>>> Richard S. Hall schrieb:
>>>
>>>> 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.
>>>>
>>>
>>> IIRC the official bundle jars als have DynamicImport-Package, but maybe
>>> a bit more specific. I think we once had static imports which resulted
>>> in the bundle jars being unusable due to required dependencies (see your
>>> third point below).
>>>
>>
>> I am not saying that the official bundles will solve the issue, but at
>> least we can wash our hands of it since they are not our artifacts.
>>
>>>> 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 would apply the same order, though I don't particularly like number 2
>>> due to the "hard" dependencies, unless those are declared optional.
>>>
>>
>> Optional dependencies are no better than dynamic ones in this case
>> because it will still allow the packages to be used without having their
>> _real_ dependencies resolved. The issue is that we are pretending the
>> dependencies are optional to avoid having to deal with resolving the
>> dependencies since it is a pain. A recipe for disaster.
>>
>>>> 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?
>>>>
>>>
>>> I am split on this. Consider a logging bundle which exports the OSGi Log
>>> Service API. Almost all bundles will wire to that due to this. Then
>>> updating the log bundle will cause massive rewiring....
>>>
>>> I don't think, that this is really the intent. So while I agree, that
>>> implementations should generally also export the respective official
>>> OSGi API, we might still want to have a specific "OSGi API bundle".
>>>
>>
>> Well, I think we already encourage people to do this and this was (is?)
>> recommended by the spec. You are correct, though, that it creates some
>> issues if you want to refresh.
>>
>> However, if you fix an impl detail in the impl bundle, then it is not
>> necessary to refresh the framework, since the older bundle revision will
>> still be exporting its API packages and the new revision can just wire
>> to those packages. The impl just needs to remember to export/import the
>> API packages. Then refreshing can happen at your leisure.
>
> Ok, then I am also in favor of dropping it.
>
> Regards
> Felix
>
>>
>> -> richard
>>
>>
>
--
Karl Pauls
karlpauls@gmail.com
Re: OSGi core and compendium bundles
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
Richard S. Hall schrieb:
> On 5/15/09 1:50 PM, Felix Meschberger wrote:
>> Hi,
>>
>> Richard S. Hall schrieb:
>>
>>> 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.
>>>
>>
>> IIRC the official bundle jars als have DynamicImport-Package, but maybe
>> a bit more specific. I think we once had static imports which resulted
>> in the bundle jars being unusable due to required dependencies (see your
>> third point below).
>>
>
> I am not saying that the official bundles will solve the issue, but at
> least we can wash our hands of it since they are not our artifacts.
>
>>> 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 would apply the same order, though I don't particularly like number 2
>> due to the "hard" dependencies, unless those are declared optional.
>>
>
> Optional dependencies are no better than dynamic ones in this case
> because it will still allow the packages to be used without having their
> _real_ dependencies resolved. The issue is that we are pretending the
> dependencies are optional to avoid having to deal with resolving the
> dependencies since it is a pain. A recipe for disaster.
>
>>> 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?
>>>
>>
>> I am split on this. Consider a logging bundle which exports the OSGi Log
>> Service API. Almost all bundles will wire to that due to this. Then
>> updating the log bundle will cause massive rewiring....
>>
>> I don't think, that this is really the intent. So while I agree, that
>> implementations should generally also export the respective official
>> OSGi API, we might still want to have a specific "OSGi API bundle".
>>
>
> Well, I think we already encourage people to do this and this was (is?)
> recommended by the spec. You are correct, though, that it creates some
> issues if you want to refresh.
>
> However, if you fix an impl detail in the impl bundle, then it is not
> necessary to refresh the framework, since the older bundle revision will
> still be exporting its API packages and the new revision can just wire
> to those packages. The impl just needs to remember to export/import the
> API packages. Then refreshing can happen at your leisure.
Ok, then I am also in favor of dropping it.
Regards
Felix
>
> -> richard
>
>
Re: OSGi core and compendium bundles
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 5/15/09 1:50 PM, Felix Meschberger wrote:
> Hi,
>
> Richard S. Hall schrieb:
>
>> 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.
>>
>
> IIRC the official bundle jars als have DynamicImport-Package, but maybe
> a bit more specific. I think we once had static imports which resulted
> in the bundle jars being unusable due to required dependencies (see your
> third point below).
>
I am not saying that the official bundles will solve the issue, but at
least we can wash our hands of it since they are not our artifacts.
>> 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 would apply the same order, though I don't particularly like number 2
> due to the "hard" dependencies, unless those are declared optional.
>
Optional dependencies are no better than dynamic ones in this case
because it will still allow the packages to be used without having their
_real_ dependencies resolved. The issue is that we are pretending the
dependencies are optional to avoid having to deal with resolving the
dependencies since it is a pain. A recipe for disaster.
>> 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?
>>
>
> I am split on this. Consider a logging bundle which exports the OSGi Log
> Service API. Almost all bundles will wire to that due to this. Then
> updating the log bundle will cause massive rewiring....
>
> I don't think, that this is really the intent. So while I agree, that
> implementations should generally also export the respective official
> OSGi API, we might still want to have a specific "OSGi API bundle".
>
Well, I think we already encourage people to do this and this was (is?)
recommended by the spec. You are correct, though, that it creates some
issues if you want to refresh.
However, if you fix an impl detail in the impl bundle, then it is not
necessary to refresh the framework, since the older bundle revision will
still be exporting its API packages and the new revision can just wire
to those packages. The impl just needs to remember to export/import the
API packages. Then refreshing can happen at your leisure.
-> richard
Re: OSGi core and compendium bundles
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
Richard S. Hall schrieb:
> 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.
IIRC the official bundle jars als have DynamicImport-Package, but maybe
a bit more specific. I think we once had static imports which resulted
in the bundle jars being unusable due to required dependencies (see your
third point below).
>
> 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 would apply the same order, though I don't particularly like number 2
due to the "hard" dependencies, unless those are declared optional.
>
> 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?
I am split on this. Consider a logging bundle which exports the OSGi Log
Service API. Almost all bundles will wire to that due to this. Then
updating the log bundle will cause massive rewiring....
I don't think, that this is really the intent. So while I agree, that
implementations should generally also export the respective official
OSGi API, we might still want to have a specific "OSGi API bundle".
Regards
Felix
>
> -> richard
>