You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by Guillaume Nodet <gn...@gmail.com> on 2010/02/25 17:11:09 UTC

Fwd: [all] OSGI - POOL-160

Guys, can we discuss that and come back with a statement we all agree on ?


---------- Forwarded message ----------
From: Niall Pemberton <ni...@gmail.com>
Date: Thu, Feb 25, 2010 at 16:26
Subject: Re: [all] OSGI - POOL-160
To: Commons Developers List <de...@commons.apache.org>


On Thu, Feb 25, 2010 at 3:17 PM, Jörg Schaible <jo...@gmx.de> wrote:
> Hi Guillaime,
>
> Guillaume Nodet wrote at Donnerstag, 25. Februar 2010 15:49:
>
>> I just had a lively chat with Peter who kinda agreed that
>> substitutability issue is mostly important for APIs.
>>
>> Please have a look at the Felix FAQ entry:
>>   http://felix.apache.org/site/apache-felix-osgi-
> faq.html#ApacheFelixOSGiFAQ-Shouldabundleimportitsownexportedpackages%253F
>> I haven't written it, so I can't be blame for that one.
>> The last paragraph says:
>>     "The main time you want to export only, is if your bundle is
>> purely a library bundle, then its packages will only be used if they
>> are needed."
>
> what we are saying is, that none of us is an OSGi expert and before we
> published the first artifact with such information, we took the advice of
> the Apache Felix community. If they recommend now something different, we'd
> like to get some "official" blessing for the changes, simply because we
> cannot really review it.

+1

Niall


>> In all cases, the current imports *are* wrong and need to be fixed,
>> because the way they are written will fail if there is any
>> incompatible change ever introduced (whatever the version).  And I
>> don't think we should guarantee that, especially across major
>> versions.
>
> What has been released is final. We're not able to change that anymore. All
> we can do is to change the OSGi information for new releases.
>
>> Anyway, the problem is the following.
>> You install commons-pool 1.5 in the osgi framework.
>> Then you install commons-pool 1.4 later.
>> What you end up with is:
>>
>> karaf@root> osgi:list -l | grep commons-pool
>> [ 100] [Active     ] [            ] [       ] [   60]
>> mvn:commons-pool/commons-pool/1.5.4
>> [ 124] [Active     ] [            ] [       ] [   60]
>> mvn:commons-pool/commons-pool/1.4
>> karaf@root> packages:exports 100
>> Commons Pool (100): org.apache.commons.pool.impl; version=1.5.4
>> Commons Pool (100): org.apache.commons.pool; version=1.5.4
>> karaf@root> packages:exports 124
>> Apache Commons Pool Bundle (124): No active exported packages.
>> karaf@root> packages:imports 124
>> Commons Pool (100): org.apache.commons.pool.impl; version=1.5.4
>> Commons Pool (100): org.apache.commons.pool; version=1.5.4
>> karaf@root> osgi:start 170
>> Error executing command: Unresolved constraint in bundle
>> org.apache.activemq.activemq-pool [129]: package;
>> (&(package=org.apache.commons.pool.impl)(version>=1.4.0)(!
> (version>=1.5.0)))
>
> While I see an error, it does not tell me a lot ;-)
>
> - Jörg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org




-- 
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com

Re: Fwd: [all] OSGI - POOL-160

Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 2/26/10 12:11 AM, Guillaume Nodet wrote:
> Guys, can we discuss that and come back with a statement we all agree on ?
>    

Yeah, I am lost on this too.

I think the advice in the FAQ is still correct, but there is no single 
correct answer.

-> richard

>
> ---------- Forwarded message ----------
> From: Niall Pemberton<ni...@gmail.com>
> Date: Thu, Feb 25, 2010 at 16:26
> Subject: Re: [all] OSGI - POOL-160
> To: Commons Developers List<de...@commons.apache.org>
>
>
> On Thu, Feb 25, 2010 at 3:17 PM, Jörg Schaible<jo...@gmx.de>  wrote:
>    
>> Hi Guillaime,
>>
>> Guillaume Nodet wrote at Donnerstag, 25. Februar 2010 15:49:
>>
>>      
>>> I just had a lively chat with Peter who kinda agreed that
>>> substitutability issue is mostly important for APIs.
>>>
>>> Please have a look at the Felix FAQ entry:
>>>    http://felix.apache.org/site/apache-felix-osgi-
>>>        
>> faq.html#ApacheFelixOSGiFAQ-Shouldabundleimportitsownexportedpackages%253F
>>      
>>> I haven't written it, so I can't be blame for that one.
>>> The last paragraph says:
>>>      "The main time you want to export only, is if your bundle is
>>> purely a library bundle, then its packages will only be used if they
>>> are needed."
>>>        
>> what we are saying is, that none of us is an OSGi expert and before we
>> published the first artifact with such information, we took the advice of
>> the Apache Felix community. If they recommend now something different, we'd
>> like to get some "official" blessing for the changes, simply because we
>> cannot really review it.
>>      
> +1
>
> Niall
>
>
>    
>>> In all cases, the current imports *are* wrong and need to be fixed,
>>> because the way they are written will fail if there is any
>>> incompatible change ever introduced (whatever the version).  And I
>>> don't think we should guarantee that, especially across major
>>> versions.
>>>        
>> What has been released is final. We're not able to change that anymore. All
>> we can do is to change the OSGi information for new releases.
>>
>>      
>>> Anyway, the problem is the following.
>>> You install commons-pool 1.5 in the osgi framework.
>>> Then you install commons-pool 1.4 later.
>>> What you end up with is:
>>>
>>> karaf@root>  osgi:list -l | grep commons-pool
>>> [ 100] [Active     ] [            ] [       ] [   60]
>>> mvn:commons-pool/commons-pool/1.5.4
>>> [ 124] [Active     ] [            ] [       ] [   60]
>>> mvn:commons-pool/commons-pool/1.4
>>> karaf@root>  packages:exports 100
>>> Commons Pool (100): org.apache.commons.pool.impl; version=1.5.4
>>> Commons Pool (100): org.apache.commons.pool; version=1.5.4
>>> karaf@root>  packages:exports 124
>>> Apache Commons Pool Bundle (124): No active exported packages.
>>> karaf@root>  packages:imports 124
>>> Commons Pool (100): org.apache.commons.pool.impl; version=1.5.4
>>> Commons Pool (100): org.apache.commons.pool; version=1.5.4
>>> karaf@root>  osgi:start 170
>>> Error executing command: Unresolved constraint in bundle
>>> org.apache.activemq.activemq-pool [129]: package;
>>> (&(package=org.apache.commons.pool.impl)(version>=1.4.0)(!
>>>        
>> (version>=1.5.0)))
>>
>> While I see an error, it does not tell me a lot ;-)
>>
>> - Jörg
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>>      
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
>
>
>    

Re: [all] OSGI - POOL-160

Posted by Phil Steitz <ph...@gmail.com>.
Niall Pemberton wrote:
> On Thu, Feb 25, 2010 at 5:02 PM, Guillaume Nodet <gn...@gmail.com> wrote:
>> Forwarding the current discussion on felix dev list.
>> Hopefully this should settle thing a bit.
>> Both Karl and Richard says the FAQ looks clear enough (that's the one
>> I pointed you to earlier too).
> 
> Its annoying since it came up three times on dev@felix and other felix
> developers said the opposite
> 
> http://markmail.org/message/5xwuqjaycupfxwh5
> 
> I guess we go with the current advice and hope its right this time. I
> have updated the commons-parent pom.xml to not re-import the
> component's packages:
> 
> http://svn.apache.org/viewvc?view=revision&revision=916523
> 
> I have also built all the components using that version of the parent
> pom and their generated manifests are here fore review:
> 
> http://people.apache.org/~niallp/osgi-feb-2010/
> 
> Niall

Thanks, guys!

Phil
> 
> 
>> ---------- Forwarded message ----------
>> From: Guillaume Nodet <gn...@gmail.com>
>> Date: Thu, Feb 25, 2010 at 18:01
>> Subject: Re: [all] OSGI - POOL-160
>> To: dev@felix.apache.org
>>
>>
>> I think I'll foward this discussion back to their dev list and things
>> should be ok I suppose.
>>
>> On Thu, Feb 25, 2010 at 17:44, Richard S. Hall <he...@ungoverned.org> wrote:
>>> On 2/26/10 12:40 AM, Guillaume Nodet wrote:
>>>> It does not seem to be sufficient to the commons guys as the want an
>>>> "official" and expert blessing from the felix community because it
>>>> kinda contradicts the earlier statement they had from Peter which said
>>>> that importing your exported packages is a best practice in osgi.
>>>>
>>> Well, they should have talked to us. ;-)
>>>
>>> Seriously, what more can we say? The FAQ has existed for a fairly long time
>>> and our story hasn't changed. Are you suggesting that we need to change the
>>> FAQ in some way? Or are you saying that you want some official OSGi Alliance
>>> statement on this?
>>>
>>> As it stands, I think the FAQ tries to explain the issues for deciding what
>>> you should do fairly well, but we're willing to improve it if it is not
>>> clear.
>>>
>>> -> richard
>>>
>>>> On Thu, Feb 25, 2010 at 17:23, Karl Pauls<ka...@gmail.com>  wrote:
>>>>
>>>>> On Thu, Feb 25, 2010 at 5:17 PM, Guillaume Nodet<gn...@gmail.com>
>>>>>  wrote:
>>>>>
>>>>>> What is the best practices for libraries wrt to importing their own
>>>>>> exported packages.
>>>>>>
>>>>> Well, I still don't know what you want to discuss. We have this in the
>>>>> FAQ:
>>>>>
>>>>> The main time you want to export only, is if your bundle is purely a
>>>>> library bundle, then its packages will only be used if they are
>>>>> needed. Another case might be if you have tightly coupled bundles
>>>>> sharing implementation packages. However, if your bundle will be
>>>>> started and especially if the exported packages define service
>>>>> interfaces or are referenced from service interfaces, then you will
>>>>> generally want to export and import them.
>>>>>
>>>>> which seems to be good and is what seems to be not followed in the
>>>>> below use case - which causes a problem. If commons pool wouldn't
>>>>> import what it exports then everything would have been fine no?
>>>>>
>>>>> Obviously, there is now single answer to this problem but the FAQ
>>>>> seems correct to me. I guess I'm still missing the point.
>>>>>
>>>>> regards,
>>>>>
>>>>> Karl
>>>>>
>>>>>
>>>>>> On Thu, Feb 25, 2010 at 17:15, Karl Pauls<ka...@gmail.com>  wrote:
>>>>>>
>>>>>>> On Thu, Feb 25, 2010 at 5:11 PM, Guillaume Nodet<gn...@gmail.com>
>>>>>>>  wrote:
>>>>>>>
>>>>>>>> Guys, can we discuss that and come back with a statement we all agree
>>>>>>>> on ?
>>>>>>>>
>>>>>>> Discuss what?
>>>>>>>
>>>>>>> regards,
>>>>>>>
>>>>>>> Karl
>>>>>>>
>>>>>>>
>>>>>>>> ---------- Forwarded message ----------
>>>>>>>> From: Niall Pemberton<ni...@gmail.com>
>>>>>>>> Date: Thu, Feb 25, 2010 at 16:26
>>>>>>>> Subject: Re: [all] OSGI - POOL-160
>>>>>>>> To: Commons Developers List<de...@commons.apache.org>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Thu, Feb 25, 2010 at 3:17 PM, Jörg Schaible<jo...@gmx.de>
>>>>>>>>  wrote:
>>>>>>>>
>>>>>>>>> Hi Guillaime,
>>>>>>>>>
>>>>>>>>> Guillaume Nodet wrote at Donnerstag, 25. Februar 2010 15:49:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> I just had a lively chat with Peter who kinda agreed that
>>>>>>>>>> substitutability issue is mostly important for APIs.
>>>>>>>>>>
>>>>>>>>>> Please have a look at the Felix FAQ entry:
>>>>>>>>>>   http://felix.apache.org/site/apache-felix-osgi-
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> faq.html#ApacheFelixOSGiFAQ-Shouldabundleimportitsownexportedpackages%253F
>>>>>>>>>
>>>>>>>>>> I haven't written it, so I can't be blame for that one.
>>>>>>>>>> The last paragraph says:
>>>>>>>>>>     "The main time you want to export only, is if your bundle is
>>>>>>>>>> purely a library bundle, then its packages will only be used if they
>>>>>>>>>> are needed."
>>>>>>>>>>
>>>>>>>>> what we are saying is, that none of us is an OSGi expert and before
>>>>>>>>> we
>>>>>>>>> published the first artifact with such information, we took the
>>>>>>>>> advice of
>>>>>>>>> the Apache Felix community. If they recommend now something
>>>>>>>>> different, we'd
>>>>>>>>> like to get some "official" blessing for the changes, simply because
>>>>>>>>> we
>>>>>>>>> cannot really review it.
>>>>>>>>>
>>>>>>>> +1
>>>>>>>>
>>>>>>>> Niall
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>> In all cases, the current imports *are* wrong and need to be fixed,
>>>>>>>>>> because the way they are written will fail if there is any
>>>>>>>>>> incompatible change ever introduced (whatever the version).  And I
>>>>>>>>>> don't think we should guarantee that, especially across major
>>>>>>>>>> versions.
>>>>>>>>>>
>>>>>>>>> What has been released is final. We're not able to change that
>>>>>>>>> anymore. All
>>>>>>>>> we can do is to change the OSGi information for new releases.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Anyway, the problem is the following.
>>>>>>>>>> You install commons-pool 1.5 in the osgi framework.
>>>>>>>>>> Then you install commons-pool 1.4 later.
>>>>>>>>>> What you end up with is:
>>>>>>>>>>
>>>>>>>>>> karaf@root>  osgi:list -l | grep commons-pool
>>>>>>>>>> [ 100] [Active     ] [            ] [       ] [   60]
>>>>>>>>>> mvn:commons-pool/commons-pool/1.5.4
>>>>>>>>>> [ 124] [Active     ] [            ] [       ] [   60]
>>>>>>>>>> mvn:commons-pool/commons-pool/1.4
>>>>>>>>>> karaf@root>  packages:exports 100
>>>>>>>>>> Commons Pool (100): org.apache.commons.pool.impl; version=1.5.4
>>>>>>>>>> Commons Pool (100): org.apache.commons.pool; version=1.5.4
>>>>>>>>>> karaf@root>  packages:exports 124
>>>>>>>>>> Apache Commons Pool Bundle (124): No active exported packages.
>>>>>>>>>> karaf@root>  packages:imports 124
>>>>>>>>>> Commons Pool (100): org.apache.commons.pool.impl; version=1.5.4
>>>>>>>>>> Commons Pool (100): org.apache.commons.pool; version=1.5.4
>>>>>>>>>> karaf@root>  osgi:start 170
>>>>>>>>>> Error executing command: Unresolved constraint in bundle
>>>>>>>>>> org.apache.activemq.activemq-pool [129]: package;
>>>>>>>>>> (&(package=org.apache.commons.pool.impl)(version>=1.4.0)(!
>>>>>>>>>>
>>>>>>>>> (version>=1.5.0)))
>>>>>>>>>
>>>>>>>>> While I see an error, it does not tell me a lot ;-)
>>>>>>>>>
>>>>>>>>> - Jörg
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Cheers,
>>>>>>>> Guillaume Nodet
>>>>>>>> ------------------------
>>>>>>>> Blog: http://gnodet.blogspot.com/
>>>>>>>> ------------------------
>>>>>>>> Open Source SOA
>>>>>>>> http://fusesource.com
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Karl Pauls
>>>>>>> karlpauls@gmail.com
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> Cheers,
>>>>>> Guillaume Nodet
>>>>>> ------------------------
>>>>>> Blog: http://gnodet.blogspot.com/
>>>>>> ------------------------
>>>>>> Open Source SOA
>>>>>> http://fusesource.com
>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> Karl Pauls
>>>>> karlpauls@gmail.com
>>>>>
>>>>>
>>>>
>>>>
>>
>>
>> --
>> Cheers,
>> Guillaume Nodet
>> ------------------------
>> Blog: http://gnodet.blogspot.com/
>> ------------------------
>> Open Source SOA
>> http://fusesource.com
>>
>>
>>
>> --
>> Cheers,
>> Guillaume Nodet
>> ------------------------
>> Blog: http://gnodet.blogspot.com/
>> ------------------------
>> Open Source SOA
>> http://fusesource.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Re: [all] OSGI - POOL-160

Posted by Niall Pemberton <ni...@gmail.com>.
On Fri, Feb 26, 2010 at 2:45 PM, Guillaume Nodet <gn...@gmail.com> wrote:
> FWIW, I would ensure that all imported packages in OSGi have a range
> on the imported package (if they don't come from the JVM).
> For example on http://people.apache.org/~niallp/osgi-feb-2010/beanutils-MANIFEST.MF,
> the Import-Package should look like:
>
> Import-Package:
> org.apache.commons.collections.comparators;version="[1.0,2.0)",org.apache.
>  commons.collections.keyvalue;version="[1.0,2.0)",org.apache.commons.collections.list;version="[1.0,2.0)",org.
>  apache.commons.collections.set;version="[1.0,2.0)",org.apache.commons.logging;version="[1.0,2.0)"
>
> The ranges I've written above are purely wild guesses and they should
> be thought about a bit more.  Not giving a range is bound
> to problems if there is an older version deployed (which could not
> contain the needed features), or if commons ever release a new major
> version of one component and breaks backward compatibility (which is
> fine for a major version).
>
> I can try to go through all of them if you're interesed but a first
> step would be to add the following to the parent pom in the
> maven-bundle-plugin configuraiton:
>  <instructions>
>      ...
>     <_versionpolicy>[$(version;==;$(@)),$(version;+;$(@)))</_versionpolicy>
>  </instructions>
>
> The effect will be to generate a range up to (but not including) the
> next major version.  The problem is that it will only work if a
> version can be infered by the maven plugin (usually by looking at the
> manifest of the dependencies).
>
> I can help a bit on that if you're willing to go that way.

I think the problem is that although we were happy to put OSGi meta
data in our manifests I don't think the developers here are using
OSGi. We have the configuration (mostly) at the commons-parent pom
level - but I think if it requires most components having to configure
this themselves on a per-component basis - then I don't think these
will be maintained properly or people will spot when they're not
correct.

Niall


> On Fri, Feb 26, 2010 at 02:26, Niall Pemberton
> <ni...@gmail.com> wrote:
>> On Thu, Feb 25, 2010 at 5:02 PM, Guillaume Nodet <gn...@gmail.com> wrote:
>>> Forwarding the current discussion on felix dev list.
>>> Hopefully this should settle thing a bit.
>>> Both Karl and Richard says the FAQ looks clear enough (that's the one
>>> I pointed you to earlier too).
>>
>> Its annoying since it came up three times on dev@felix and other felix
>> developers said the opposite
>>
>> http://markmail.org/message/5xwuqjaycupfxwh5
>>
>> I guess we go with the current advice and hope its right this time. I
>> have updated the commons-parent pom.xml to not re-import the
>> component's packages:
>>
>> http://svn.apache.org/viewvc?view=revision&revision=916523
>>
>> I have also built all the components using that version of the parent
>> pom and their generated manifests are here fore review:
>>
>> http://people.apache.org/~niallp/osgi-feb-2010/
>>
>> Niall
>>
>>
>>> ---------- Forwarded message ----------
>>> From: Guillaume Nodet <gn...@gmail.com>
>>> Date: Thu, Feb 25, 2010 at 18:01
>>> Subject: Re: [all] OSGI - POOL-160
>>> To: dev@felix.apache.org
>>>
>>>
>>> I think I'll foward this discussion back to their dev list and things
>>> should be ok I suppose.
>>>
>>> On Thu, Feb 25, 2010 at 17:44, Richard S. Hall <he...@ungoverned.org> wrote:
>>>> On 2/26/10 12:40 AM, Guillaume Nodet wrote:
>>>>>
>>>>> It does not seem to be sufficient to the commons guys as the want an
>>>>> "official" and expert blessing from the felix community because it
>>>>> kinda contradicts the earlier statement they had from Peter which said
>>>>> that importing your exported packages is a best practice in osgi.
>>>>>
>>>>
>>>> Well, they should have talked to us. ;-)
>>>>
>>>> Seriously, what more can we say? The FAQ has existed for a fairly long time
>>>> and our story hasn't changed. Are you suggesting that we need to change the
>>>> FAQ in some way? Or are you saying that you want some official OSGi Alliance
>>>> statement on this?
>>>>
>>>> As it stands, I think the FAQ tries to explain the issues for deciding what
>>>> you should do fairly well, but we're willing to improve it if it is not
>>>> clear.
>>>>
>>>> -> richard
>>>>
>>>>> On Thu, Feb 25, 2010 at 17:23, Karl Pauls<ka...@gmail.com>  wrote:
>>>>>
>>>>>>
>>>>>> On Thu, Feb 25, 2010 at 5:17 PM, Guillaume Nodet<gn...@gmail.com>
>>>>>>  wrote:
>>>>>>
>>>>>>>
>>>>>>> What is the best practices for libraries wrt to importing their own
>>>>>>> exported packages.
>>>>>>>
>>>>>>
>>>>>> Well, I still don't know what you want to discuss. We have this in the
>>>>>> FAQ:
>>>>>>
>>>>>> The main time you want to export only, is if your bundle is purely a
>>>>>> library bundle, then its packages will only be used if they are
>>>>>> needed. Another case might be if you have tightly coupled bundles
>>>>>> sharing implementation packages. However, if your bundle will be
>>>>>> started and especially if the exported packages define service
>>>>>> interfaces or are referenced from service interfaces, then you will
>>>>>> generally want to export and import them.
>>>>>>
>>>>>> which seems to be good and is what seems to be not followed in the
>>>>>> below use case - which causes a problem. If commons pool wouldn't
>>>>>> import what it exports then everything would have been fine no?
>>>>>>
>>>>>> Obviously, there is now single answer to this problem but the FAQ
>>>>>> seems correct to me. I guess I'm still missing the point.
>>>>>>
>>>>>> regards,
>>>>>>
>>>>>> Karl
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> On Thu, Feb 25, 2010 at 17:15, Karl Pauls<ka...@gmail.com>  wrote:
>>>>>>>
>>>>>>>>
>>>>>>>> On Thu, Feb 25, 2010 at 5:11 PM, Guillaume Nodet<gn...@gmail.com>
>>>>>>>>  wrote:
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Guys, can we discuss that and come back with a statement we all agree
>>>>>>>>> on ?
>>>>>>>>>
>>>>>>>>
>>>>>>>> Discuss what?
>>>>>>>>
>>>>>>>> regards,
>>>>>>>>
>>>>>>>> Karl
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> ---------- Forwarded message ----------
>>>>>>>>> From: Niall Pemberton<ni...@gmail.com>
>>>>>>>>> Date: Thu, Feb 25, 2010 at 16:26
>>>>>>>>> Subject: Re: [all] OSGI - POOL-160
>>>>>>>>> To: Commons Developers List<de...@commons.apache.org>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Thu, Feb 25, 2010 at 3:17 PM, Jörg Schaible<jo...@gmx.de>
>>>>>>>>>  wrote:
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Hi Guillaime,
>>>>>>>>>>
>>>>>>>>>> Guillaume Nodet wrote at Donnerstag, 25. Februar 2010 15:49:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> I just had a lively chat with Peter who kinda agreed that
>>>>>>>>>>> substitutability issue is mostly important for APIs.
>>>>>>>>>>>
>>>>>>>>>>> Please have a look at the Felix FAQ entry:
>>>>>>>>>>>   http://felix.apache.org/site/apache-felix-osgi-
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> faq.html#ApacheFelixOSGiFAQ-Shouldabundleimportitsownexportedpackages%253F
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> I haven't written it, so I can't be blame for that one.
>>>>>>>>>>> The last paragraph says:
>>>>>>>>>>>     "The main time you want to export only, is if your bundle is
>>>>>>>>>>> purely a library bundle, then its packages will only be used if they
>>>>>>>>>>> are needed."
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> what we are saying is, that none of us is an OSGi expert and before
>>>>>>>>>> we
>>>>>>>>>> published the first artifact with such information, we took the
>>>>>>>>>> advice of
>>>>>>>>>> the Apache Felix community. If they recommend now something
>>>>>>>>>> different, we'd
>>>>>>>>>> like to get some "official" blessing for the changes, simply because
>>>>>>>>>> we
>>>>>>>>>> cannot really review it.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> +1
>>>>>>>>>
>>>>>>>>> Niall
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> In all cases, the current imports *are* wrong and need to be fixed,
>>>>>>>>>>> because the way they are written will fail if there is any
>>>>>>>>>>> incompatible change ever introduced (whatever the version).  And I
>>>>>>>>>>> don't think we should guarantee that, especially across major
>>>>>>>>>>> versions.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> What has been released is final. We're not able to change that
>>>>>>>>>> anymore. All
>>>>>>>>>> we can do is to change the OSGi information for new releases.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Anyway, the problem is the following.
>>>>>>>>>>> You install commons-pool 1.5 in the osgi framework.
>>>>>>>>>>> Then you install commons-pool 1.4 later.
>>>>>>>>>>> What you end up with is:
>>>>>>>>>>>
>>>>>>>>>>> karaf@root>  osgi:list -l | grep commons-pool
>>>>>>>>>>> [ 100] [Active     ] [            ] [       ] [   60]
>>>>>>>>>>> mvn:commons-pool/commons-pool/1.5.4
>>>>>>>>>>> [ 124] [Active     ] [            ] [       ] [   60]
>>>>>>>>>>> mvn:commons-pool/commons-pool/1.4
>>>>>>>>>>> karaf@root>  packages:exports 100
>>>>>>>>>>> Commons Pool (100): org.apache.commons.pool.impl; version=1.5.4
>>>>>>>>>>> Commons Pool (100): org.apache.commons.pool; version=1.5.4
>>>>>>>>>>> karaf@root>  packages:exports 124
>>>>>>>>>>> Apache Commons Pool Bundle (124): No active exported packages.
>>>>>>>>>>> karaf@root>  packages:imports 124
>>>>>>>>>>> Commons Pool (100): org.apache.commons.pool.impl; version=1.5.4
>>>>>>>>>>> Commons Pool (100): org.apache.commons.pool; version=1.5.4
>>>>>>>>>>> karaf@root>  osgi:start 170
>>>>>>>>>>> Error executing command: Unresolved constraint in bundle
>>>>>>>>>>> org.apache.activemq.activemq-pool [129]: package;
>>>>>>>>>>> (&(package=org.apache.commons.pool.impl)(version>=1.4.0)(!
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> (version>=1.5.0)))
>>>>>>>>>>
>>>>>>>>>> While I see an error, it does not tell me a lot ;-)
>>>>>>>>>>
>>>>>>>>>> - Jörg
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Cheers,
>>>>>>>>> Guillaume Nodet
>>>>>>>>> ------------------------
>>>>>>>>> Blog: http://gnodet.blogspot.com/
>>>>>>>>> ------------------------
>>>>>>>>> Open Source SOA
>>>>>>>>> http://fusesource.com
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Karl Pauls
>>>>>>>> karlpauls@gmail.com
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Cheers,
>>>>>>> Guillaume Nodet
>>>>>>> ------------------------
>>>>>>> Blog: http://gnodet.blogspot.com/
>>>>>>> ------------------------
>>>>>>> Open Source SOA
>>>>>>> http://fusesource.com
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Karl Pauls
>>>>>> karlpauls@gmail.com
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> Cheers,
>>> Guillaume Nodet
>>> ------------------------
>>> Blog: http://gnodet.blogspot.com/
>>> ------------------------
>>> Open Source SOA
>>> http://fusesource.com
>>>
>>>
>>>
>>> --
>>> Cheers,
>>> Guillaume Nodet
>>> ------------------------
>>> Blog: http://gnodet.blogspot.com/
>>> ------------------------
>>> Open Source SOA
>>> http://fusesource.com
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Re: [all] OSGI - POOL-160

Posted by Guillaume Nodet <gn...@gmail.com>.
FWIW, I would ensure that all imported packages in OSGi have a range
on the imported package (if they don't come from the JVM).
For example on http://people.apache.org/~niallp/osgi-feb-2010/beanutils-MANIFEST.MF,
the Import-Package should look like:

Import-Package:
org.apache.commons.collections.comparators;version="[1.0,2.0)",org.apache.
 commons.collections.keyvalue;version="[1.0,2.0)",org.apache.commons.collections.list;version="[1.0,2.0)",org.
 apache.commons.collections.set;version="[1.0,2.0)",org.apache.commons.logging;version="[1.0,2.0)"

The ranges I've written above are purely wild guesses and they should
be thought about a bit more.  Not giving a range is bound
to problems if there is an older version deployed (which could not
contain the needed features), or if commons ever release a new major
version of one component and breaks backward compatibility (which is
fine for a major version).

I can try to go through all of them if you're interesed but a first
step would be to add the following to the parent pom in the
maven-bundle-plugin configuraiton:
  <instructions>
      ...
     <_versionpolicy>[$(version;==;$(@)),$(version;+;$(@)))</_versionpolicy>
  </instructions>

The effect will be to generate a range up to (but not including) the
next major version.  The problem is that it will only work if a
version can be infered by the maven plugin (usually by looking at the
manifest of the dependencies).

I can help a bit on that if you're willing to go that way.

On Fri, Feb 26, 2010 at 02:26, Niall Pemberton
<ni...@gmail.com> wrote:
> On Thu, Feb 25, 2010 at 5:02 PM, Guillaume Nodet <gn...@gmail.com> wrote:
>> Forwarding the current discussion on felix dev list.
>> Hopefully this should settle thing a bit.
>> Both Karl and Richard says the FAQ looks clear enough (that's the one
>> I pointed you to earlier too).
>
> Its annoying since it came up three times on dev@felix and other felix
> developers said the opposite
>
> http://markmail.org/message/5xwuqjaycupfxwh5
>
> I guess we go with the current advice and hope its right this time. I
> have updated the commons-parent pom.xml to not re-import the
> component's packages:
>
> http://svn.apache.org/viewvc?view=revision&revision=916523
>
> I have also built all the components using that version of the parent
> pom and their generated manifests are here fore review:
>
> http://people.apache.org/~niallp/osgi-feb-2010/
>
> Niall
>
>
>> ---------- Forwarded message ----------
>> From: Guillaume Nodet <gn...@gmail.com>
>> Date: Thu, Feb 25, 2010 at 18:01
>> Subject: Re: [all] OSGI - POOL-160
>> To: dev@felix.apache.org
>>
>>
>> I think I'll foward this discussion back to their dev list and things
>> should be ok I suppose.
>>
>> On Thu, Feb 25, 2010 at 17:44, Richard S. Hall <he...@ungoverned.org> wrote:
>>> On 2/26/10 12:40 AM, Guillaume Nodet wrote:
>>>>
>>>> It does not seem to be sufficient to the commons guys as the want an
>>>> "official" and expert blessing from the felix community because it
>>>> kinda contradicts the earlier statement they had from Peter which said
>>>> that importing your exported packages is a best practice in osgi.
>>>>
>>>
>>> Well, they should have talked to us. ;-)
>>>
>>> Seriously, what more can we say? The FAQ has existed for a fairly long time
>>> and our story hasn't changed. Are you suggesting that we need to change the
>>> FAQ in some way? Or are you saying that you want some official OSGi Alliance
>>> statement on this?
>>>
>>> As it stands, I think the FAQ tries to explain the issues for deciding what
>>> you should do fairly well, but we're willing to improve it if it is not
>>> clear.
>>>
>>> -> richard
>>>
>>>> On Thu, Feb 25, 2010 at 17:23, Karl Pauls<ka...@gmail.com>  wrote:
>>>>
>>>>>
>>>>> On Thu, Feb 25, 2010 at 5:17 PM, Guillaume Nodet<gn...@gmail.com>
>>>>>  wrote:
>>>>>
>>>>>>
>>>>>> What is the best practices for libraries wrt to importing their own
>>>>>> exported packages.
>>>>>>
>>>>>
>>>>> Well, I still don't know what you want to discuss. We have this in the
>>>>> FAQ:
>>>>>
>>>>> The main time you want to export only, is if your bundle is purely a
>>>>> library bundle, then its packages will only be used if they are
>>>>> needed. Another case might be if you have tightly coupled bundles
>>>>> sharing implementation packages. However, if your bundle will be
>>>>> started and especially if the exported packages define service
>>>>> interfaces or are referenced from service interfaces, then you will
>>>>> generally want to export and import them.
>>>>>
>>>>> which seems to be good and is what seems to be not followed in the
>>>>> below use case - which causes a problem. If commons pool wouldn't
>>>>> import what it exports then everything would have been fine no?
>>>>>
>>>>> Obviously, there is now single answer to this problem but the FAQ
>>>>> seems correct to me. I guess I'm still missing the point.
>>>>>
>>>>> regards,
>>>>>
>>>>> Karl
>>>>>
>>>>>
>>>>>>
>>>>>> On Thu, Feb 25, 2010 at 17:15, Karl Pauls<ka...@gmail.com>  wrote:
>>>>>>
>>>>>>>
>>>>>>> On Thu, Feb 25, 2010 at 5:11 PM, Guillaume Nodet<gn...@gmail.com>
>>>>>>>  wrote:
>>>>>>>
>>>>>>>>
>>>>>>>> Guys, can we discuss that and come back with a statement we all agree
>>>>>>>> on ?
>>>>>>>>
>>>>>>>
>>>>>>> Discuss what?
>>>>>>>
>>>>>>> regards,
>>>>>>>
>>>>>>> Karl
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> ---------- Forwarded message ----------
>>>>>>>> From: Niall Pemberton<ni...@gmail.com>
>>>>>>>> Date: Thu, Feb 25, 2010 at 16:26
>>>>>>>> Subject: Re: [all] OSGI - POOL-160
>>>>>>>> To: Commons Developers List<de...@commons.apache.org>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Thu, Feb 25, 2010 at 3:17 PM, Jörg Schaible<jo...@gmx.de>
>>>>>>>>  wrote:
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Hi Guillaime,
>>>>>>>>>
>>>>>>>>> Guillaume Nodet wrote at Donnerstag, 25. Februar 2010 15:49:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I just had a lively chat with Peter who kinda agreed that
>>>>>>>>>> substitutability issue is mostly important for APIs.
>>>>>>>>>>
>>>>>>>>>> Please have a look at the Felix FAQ entry:
>>>>>>>>>>   http://felix.apache.org/site/apache-felix-osgi-
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> faq.html#ApacheFelixOSGiFAQ-Shouldabundleimportitsownexportedpackages%253F
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I haven't written it, so I can't be blame for that one.
>>>>>>>>>> The last paragraph says:
>>>>>>>>>>     "The main time you want to export only, is if your bundle is
>>>>>>>>>> purely a library bundle, then its packages will only be used if they
>>>>>>>>>> are needed."
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> what we are saying is, that none of us is an OSGi expert and before
>>>>>>>>> we
>>>>>>>>> published the first artifact with such information, we took the
>>>>>>>>> advice of
>>>>>>>>> the Apache Felix community. If they recommend now something
>>>>>>>>> different, we'd
>>>>>>>>> like to get some "official" blessing for the changes, simply because
>>>>>>>>> we
>>>>>>>>> cannot really review it.
>>>>>>>>>
>>>>>>>>
>>>>>>>> +1
>>>>>>>>
>>>>>>>> Niall
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> In all cases, the current imports *are* wrong and need to be fixed,
>>>>>>>>>> because the way they are written will fail if there is any
>>>>>>>>>> incompatible change ever introduced (whatever the version).  And I
>>>>>>>>>> don't think we should guarantee that, especially across major
>>>>>>>>>> versions.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> What has been released is final. We're not able to change that
>>>>>>>>> anymore. All
>>>>>>>>> we can do is to change the OSGi information for new releases.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Anyway, the problem is the following.
>>>>>>>>>> You install commons-pool 1.5 in the osgi framework.
>>>>>>>>>> Then you install commons-pool 1.4 later.
>>>>>>>>>> What you end up with is:
>>>>>>>>>>
>>>>>>>>>> karaf@root>  osgi:list -l | grep commons-pool
>>>>>>>>>> [ 100] [Active     ] [            ] [       ] [   60]
>>>>>>>>>> mvn:commons-pool/commons-pool/1.5.4
>>>>>>>>>> [ 124] [Active     ] [            ] [       ] [   60]
>>>>>>>>>> mvn:commons-pool/commons-pool/1.4
>>>>>>>>>> karaf@root>  packages:exports 100
>>>>>>>>>> Commons Pool (100): org.apache.commons.pool.impl; version=1.5.4
>>>>>>>>>> Commons Pool (100): org.apache.commons.pool; version=1.5.4
>>>>>>>>>> karaf@root>  packages:exports 124
>>>>>>>>>> Apache Commons Pool Bundle (124): No active exported packages.
>>>>>>>>>> karaf@root>  packages:imports 124
>>>>>>>>>> Commons Pool (100): org.apache.commons.pool.impl; version=1.5.4
>>>>>>>>>> Commons Pool (100): org.apache.commons.pool; version=1.5.4
>>>>>>>>>> karaf@root>  osgi:start 170
>>>>>>>>>> Error executing command: Unresolved constraint in bundle
>>>>>>>>>> org.apache.activemq.activemq-pool [129]: package;
>>>>>>>>>> (&(package=org.apache.commons.pool.impl)(version>=1.4.0)(!
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> (version>=1.5.0)))
>>>>>>>>>
>>>>>>>>> While I see an error, it does not tell me a lot ;-)
>>>>>>>>>
>>>>>>>>> - Jörg
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Cheers,
>>>>>>>> Guillaume Nodet
>>>>>>>> ------------------------
>>>>>>>> Blog: http://gnodet.blogspot.com/
>>>>>>>> ------------------------
>>>>>>>> Open Source SOA
>>>>>>>> http://fusesource.com
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Karl Pauls
>>>>>>> karlpauls@gmail.com
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Cheers,
>>>>>> Guillaume Nodet
>>>>>> ------------------------
>>>>>> Blog: http://gnodet.blogspot.com/
>>>>>> ------------------------
>>>>>> Open Source SOA
>>>>>> http://fusesource.com
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Karl Pauls
>>>>> karlpauls@gmail.com
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>
>>
>>
>> --
>> Cheers,
>> Guillaume Nodet
>> ------------------------
>> Blog: http://gnodet.blogspot.com/
>> ------------------------
>> Open Source SOA
>> http://fusesource.com
>>
>>
>>
>> --
>> Cheers,
>> Guillaume Nodet
>> ------------------------
>> Blog: http://gnodet.blogspot.com/
>> ------------------------
>> Open Source SOA
>> http://fusesource.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>



-- 
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Re: [all] OSGI - POOL-160

Posted by Niall Pemberton <ni...@gmail.com>.
On Thu, Feb 25, 2010 at 5:02 PM, Guillaume Nodet <gn...@gmail.com> wrote:
> Forwarding the current discussion on felix dev list.
> Hopefully this should settle thing a bit.
> Both Karl and Richard says the FAQ looks clear enough (that's the one
> I pointed you to earlier too).

Its annoying since it came up three times on dev@felix and other felix
developers said the opposite

http://markmail.org/message/5xwuqjaycupfxwh5

I guess we go with the current advice and hope its right this time. I
have updated the commons-parent pom.xml to not re-import the
component's packages:

http://svn.apache.org/viewvc?view=revision&revision=916523

I have also built all the components using that version of the parent
pom and their generated manifests are here fore review:

http://people.apache.org/~niallp/osgi-feb-2010/

Niall


> ---------- Forwarded message ----------
> From: Guillaume Nodet <gn...@gmail.com>
> Date: Thu, Feb 25, 2010 at 18:01
> Subject: Re: [all] OSGI - POOL-160
> To: dev@felix.apache.org
>
>
> I think I'll foward this discussion back to their dev list and things
> should be ok I suppose.
>
> On Thu, Feb 25, 2010 at 17:44, Richard S. Hall <he...@ungoverned.org> wrote:
>> On 2/26/10 12:40 AM, Guillaume Nodet wrote:
>>>
>>> It does not seem to be sufficient to the commons guys as the want an
>>> "official" and expert blessing from the felix community because it
>>> kinda contradicts the earlier statement they had from Peter which said
>>> that importing your exported packages is a best practice in osgi.
>>>
>>
>> Well, they should have talked to us. ;-)
>>
>> Seriously, what more can we say? The FAQ has existed for a fairly long time
>> and our story hasn't changed. Are you suggesting that we need to change the
>> FAQ in some way? Or are you saying that you want some official OSGi Alliance
>> statement on this?
>>
>> As it stands, I think the FAQ tries to explain the issues for deciding what
>> you should do fairly well, but we're willing to improve it if it is not
>> clear.
>>
>> -> richard
>>
>>> On Thu, Feb 25, 2010 at 17:23, Karl Pauls<ka...@gmail.com>  wrote:
>>>
>>>>
>>>> On Thu, Feb 25, 2010 at 5:17 PM, Guillaume Nodet<gn...@gmail.com>
>>>>  wrote:
>>>>
>>>>>
>>>>> What is the best practices for libraries wrt to importing their own
>>>>> exported packages.
>>>>>
>>>>
>>>> Well, I still don't know what you want to discuss. We have this in the
>>>> FAQ:
>>>>
>>>> The main time you want to export only, is if your bundle is purely a
>>>> library bundle, then its packages will only be used if they are
>>>> needed. Another case might be if you have tightly coupled bundles
>>>> sharing implementation packages. However, if your bundle will be
>>>> started and especially if the exported packages define service
>>>> interfaces or are referenced from service interfaces, then you will
>>>> generally want to export and import them.
>>>>
>>>> which seems to be good and is what seems to be not followed in the
>>>> below use case - which causes a problem. If commons pool wouldn't
>>>> import what it exports then everything would have been fine no?
>>>>
>>>> Obviously, there is now single answer to this problem but the FAQ
>>>> seems correct to me. I guess I'm still missing the point.
>>>>
>>>> regards,
>>>>
>>>> Karl
>>>>
>>>>
>>>>>
>>>>> On Thu, Feb 25, 2010 at 17:15, Karl Pauls<ka...@gmail.com>  wrote:
>>>>>
>>>>>>
>>>>>> On Thu, Feb 25, 2010 at 5:11 PM, Guillaume Nodet<gn...@gmail.com>
>>>>>>  wrote:
>>>>>>
>>>>>>>
>>>>>>> Guys, can we discuss that and come back with a statement we all agree
>>>>>>> on ?
>>>>>>>
>>>>>>
>>>>>> Discuss what?
>>>>>>
>>>>>> regards,
>>>>>>
>>>>>> Karl
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> ---------- Forwarded message ----------
>>>>>>> From: Niall Pemberton<ni...@gmail.com>
>>>>>>> Date: Thu, Feb 25, 2010 at 16:26
>>>>>>> Subject: Re: [all] OSGI - POOL-160
>>>>>>> To: Commons Developers List<de...@commons.apache.org>
>>>>>>>
>>>>>>>
>>>>>>> On Thu, Feb 25, 2010 at 3:17 PM, Jörg Schaible<jo...@gmx.de>
>>>>>>>  wrote:
>>>>>>>
>>>>>>>>
>>>>>>>> Hi Guillaime,
>>>>>>>>
>>>>>>>> Guillaume Nodet wrote at Donnerstag, 25. Februar 2010 15:49:
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> I just had a lively chat with Peter who kinda agreed that
>>>>>>>>> substitutability issue is mostly important for APIs.
>>>>>>>>>
>>>>>>>>> Please have a look at the Felix FAQ entry:
>>>>>>>>>   http://felix.apache.org/site/apache-felix-osgi-
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> faq.html#ApacheFelixOSGiFAQ-Shouldabundleimportitsownexportedpackages%253F
>>>>>>>>
>>>>>>>>>
>>>>>>>>> I haven't written it, so I can't be blame for that one.
>>>>>>>>> The last paragraph says:
>>>>>>>>>     "The main time you want to export only, is if your bundle is
>>>>>>>>> purely a library bundle, then its packages will only be used if they
>>>>>>>>> are needed."
>>>>>>>>>
>>>>>>>>
>>>>>>>> what we are saying is, that none of us is an OSGi expert and before
>>>>>>>> we
>>>>>>>> published the first artifact with such information, we took the
>>>>>>>> advice of
>>>>>>>> the Apache Felix community. If they recommend now something
>>>>>>>> different, we'd
>>>>>>>> like to get some "official" blessing for the changes, simply because
>>>>>>>> we
>>>>>>>> cannot really review it.
>>>>>>>>
>>>>>>>
>>>>>>> +1
>>>>>>>
>>>>>>> Niall
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>
>>>>>>>>> In all cases, the current imports *are* wrong and need to be fixed,
>>>>>>>>> because the way they are written will fail if there is any
>>>>>>>>> incompatible change ever introduced (whatever the version).  And I
>>>>>>>>> don't think we should guarantee that, especially across major
>>>>>>>>> versions.
>>>>>>>>>
>>>>>>>>
>>>>>>>> What has been released is final. We're not able to change that
>>>>>>>> anymore. All
>>>>>>>> we can do is to change the OSGi information for new releases.
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Anyway, the problem is the following.
>>>>>>>>> You install commons-pool 1.5 in the osgi framework.
>>>>>>>>> Then you install commons-pool 1.4 later.
>>>>>>>>> What you end up with is:
>>>>>>>>>
>>>>>>>>> karaf@root>  osgi:list -l | grep commons-pool
>>>>>>>>> [ 100] [Active     ] [            ] [       ] [   60]
>>>>>>>>> mvn:commons-pool/commons-pool/1.5.4
>>>>>>>>> [ 124] [Active     ] [            ] [       ] [   60]
>>>>>>>>> mvn:commons-pool/commons-pool/1.4
>>>>>>>>> karaf@root>  packages:exports 100
>>>>>>>>> Commons Pool (100): org.apache.commons.pool.impl; version=1.5.4
>>>>>>>>> Commons Pool (100): org.apache.commons.pool; version=1.5.4
>>>>>>>>> karaf@root>  packages:exports 124
>>>>>>>>> Apache Commons Pool Bundle (124): No active exported packages.
>>>>>>>>> karaf@root>  packages:imports 124
>>>>>>>>> Commons Pool (100): org.apache.commons.pool.impl; version=1.5.4
>>>>>>>>> Commons Pool (100): org.apache.commons.pool; version=1.5.4
>>>>>>>>> karaf@root>  osgi:start 170
>>>>>>>>> Error executing command: Unresolved constraint in bundle
>>>>>>>>> org.apache.activemq.activemq-pool [129]: package;
>>>>>>>>> (&(package=org.apache.commons.pool.impl)(version>=1.4.0)(!
>>>>>>>>>
>>>>>>>>
>>>>>>>> (version>=1.5.0)))
>>>>>>>>
>>>>>>>> While I see an error, it does not tell me a lot ;-)
>>>>>>>>
>>>>>>>> - Jörg
>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Cheers,
>>>>>>> Guillaume Nodet
>>>>>>> ------------------------
>>>>>>> Blog: http://gnodet.blogspot.com/
>>>>>>> ------------------------
>>>>>>> Open Source SOA
>>>>>>> http://fusesource.com
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Karl Pauls
>>>>>> karlpauls@gmail.com
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Cheers,
>>>>> Guillaume Nodet
>>>>> ------------------------
>>>>> Blog: http://gnodet.blogspot.com/
>>>>> ------------------------
>>>>> Open Source SOA
>>>>> http://fusesource.com
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Karl Pauls
>>>> karlpauls@gmail.com
>>>>
>>>>
>>>
>>>
>>>
>>
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Fwd: [all] OSGI - POOL-160

Posted by Guillaume Nodet <gn...@gmail.com>.
Forwarding the current discussion on felix dev list.
Hopefully this should settle thing a bit.
Both Karl and Richard says the FAQ looks clear enough (that's the one
I pointed you to earlier too).


---------- Forwarded message ----------
From: Guillaume Nodet <gn...@gmail.com>
Date: Thu, Feb 25, 2010 at 18:01
Subject: Re: [all] OSGI - POOL-160
To: dev@felix.apache.org


I think I'll foward this discussion back to their dev list and things
should be ok I suppose.

On Thu, Feb 25, 2010 at 17:44, Richard S. Hall <he...@ungoverned.org> wrote:
> On 2/26/10 12:40 AM, Guillaume Nodet wrote:
>>
>> It does not seem to be sufficient to the commons guys as the want an
>> "official" and expert blessing from the felix community because it
>> kinda contradicts the earlier statement they had from Peter which said
>> that importing your exported packages is a best practice in osgi.
>>
>
> Well, they should have talked to us. ;-)
>
> Seriously, what more can we say? The FAQ has existed for a fairly long time
> and our story hasn't changed. Are you suggesting that we need to change the
> FAQ in some way? Or are you saying that you want some official OSGi Alliance
> statement on this?
>
> As it stands, I think the FAQ tries to explain the issues for deciding what
> you should do fairly well, but we're willing to improve it if it is not
> clear.
>
> -> richard
>
>> On Thu, Feb 25, 2010 at 17:23, Karl Pauls<ka...@gmail.com>  wrote:
>>
>>>
>>> On Thu, Feb 25, 2010 at 5:17 PM, Guillaume Nodet<gn...@gmail.com>
>>>  wrote:
>>>
>>>>
>>>> What is the best practices for libraries wrt to importing their own
>>>> exported packages.
>>>>
>>>
>>> Well, I still don't know what you want to discuss. We have this in the
>>> FAQ:
>>>
>>> The main time you want to export only, is if your bundle is purely a
>>> library bundle, then its packages will only be used if they are
>>> needed. Another case might be if you have tightly coupled bundles
>>> sharing implementation packages. However, if your bundle will be
>>> started and especially if the exported packages define service
>>> interfaces or are referenced from service interfaces, then you will
>>> generally want to export and import them.
>>>
>>> which seems to be good and is what seems to be not followed in the
>>> below use case - which causes a problem. If commons pool wouldn't
>>> import what it exports then everything would have been fine no?
>>>
>>> Obviously, there is now single answer to this problem but the FAQ
>>> seems correct to me. I guess I'm still missing the point.
>>>
>>> regards,
>>>
>>> Karl
>>>
>>>
>>>>
>>>> On Thu, Feb 25, 2010 at 17:15, Karl Pauls<ka...@gmail.com>  wrote:
>>>>
>>>>>
>>>>> On Thu, Feb 25, 2010 at 5:11 PM, Guillaume Nodet<gn...@gmail.com>
>>>>>  wrote:
>>>>>
>>>>>>
>>>>>> Guys, can we discuss that and come back with a statement we all agree
>>>>>> on ?
>>>>>>
>>>>>
>>>>> Discuss what?
>>>>>
>>>>> regards,
>>>>>
>>>>> Karl
>>>>>
>>>>>
>>>>>>
>>>>>> ---------- Forwarded message ----------
>>>>>> From: Niall Pemberton<ni...@gmail.com>
>>>>>> Date: Thu, Feb 25, 2010 at 16:26
>>>>>> Subject: Re: [all] OSGI - POOL-160
>>>>>> To: Commons Developers List<de...@commons.apache.org>
>>>>>>
>>>>>>
>>>>>> On Thu, Feb 25, 2010 at 3:17 PM, Jörg Schaible<jo...@gmx.de>
>>>>>>  wrote:
>>>>>>
>>>>>>>
>>>>>>> Hi Guillaime,
>>>>>>>
>>>>>>> Guillaume Nodet wrote at Donnerstag, 25. Februar 2010 15:49:
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> I just had a lively chat with Peter who kinda agreed that
>>>>>>>> substitutability issue is mostly important for APIs.
>>>>>>>>
>>>>>>>> Please have a look at the Felix FAQ entry:
>>>>>>>>   http://felix.apache.org/site/apache-felix-osgi-
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> faq.html#ApacheFelixOSGiFAQ-Shouldabundleimportitsownexportedpackages%253F
>>>>>>>
>>>>>>>>
>>>>>>>> I haven't written it, so I can't be blame for that one.
>>>>>>>> The last paragraph says:
>>>>>>>>     "The main time you want to export only, is if your bundle is
>>>>>>>> purely a library bundle, then its packages will only be used if they
>>>>>>>> are needed."
>>>>>>>>
>>>>>>>
>>>>>>> what we are saying is, that none of us is an OSGi expert and before
>>>>>>> we
>>>>>>> published the first artifact with such information, we took the
>>>>>>> advice of
>>>>>>> the Apache Felix community. If they recommend now something
>>>>>>> different, we'd
>>>>>>> like to get some "official" blessing for the changes, simply because
>>>>>>> we
>>>>>>> cannot really review it.
>>>>>>>
>>>>>>
>>>>>> +1
>>>>>>
>>>>>> Niall
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>
>>>>>>>> In all cases, the current imports *are* wrong and need to be fixed,
>>>>>>>> because the way they are written will fail if there is any
>>>>>>>> incompatible change ever introduced (whatever the version).  And I
>>>>>>>> don't think we should guarantee that, especially across major
>>>>>>>> versions.
>>>>>>>>
>>>>>>>
>>>>>>> What has been released is final. We're not able to change that
>>>>>>> anymore. All
>>>>>>> we can do is to change the OSGi information for new releases.
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> Anyway, the problem is the following.
>>>>>>>> You install commons-pool 1.5 in the osgi framework.
>>>>>>>> Then you install commons-pool 1.4 later.
>>>>>>>> What you end up with is:
>>>>>>>>
>>>>>>>> karaf@root>  osgi:list -l | grep commons-pool
>>>>>>>> [ 100] [Active     ] [            ] [       ] [   60]
>>>>>>>> mvn:commons-pool/commons-pool/1.5.4
>>>>>>>> [ 124] [Active     ] [            ] [       ] [   60]
>>>>>>>> mvn:commons-pool/commons-pool/1.4
>>>>>>>> karaf@root>  packages:exports 100
>>>>>>>> Commons Pool (100): org.apache.commons.pool.impl; version=1.5.4
>>>>>>>> Commons Pool (100): org.apache.commons.pool; version=1.5.4
>>>>>>>> karaf@root>  packages:exports 124
>>>>>>>> Apache Commons Pool Bundle (124): No active exported packages.
>>>>>>>> karaf@root>  packages:imports 124
>>>>>>>> Commons Pool (100): org.apache.commons.pool.impl; version=1.5.4
>>>>>>>> Commons Pool (100): org.apache.commons.pool; version=1.5.4
>>>>>>>> karaf@root>  osgi:start 170
>>>>>>>> Error executing command: Unresolved constraint in bundle
>>>>>>>> org.apache.activemq.activemq-pool [129]: package;
>>>>>>>> (&(package=org.apache.commons.pool.impl)(version>=1.4.0)(!
>>>>>>>>
>>>>>>>
>>>>>>> (version>=1.5.0)))
>>>>>>>
>>>>>>> While I see an error, it does not tell me a lot ;-)
>>>>>>>
>>>>>>> - Jörg
>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Cheers,
>>>>>> Guillaume Nodet
>>>>>> ------------------------
>>>>>> Blog: http://gnodet.blogspot.com/
>>>>>> ------------------------
>>>>>> Open Source SOA
>>>>>> http://fusesource.com
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Karl Pauls
>>>>> karlpauls@gmail.com
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Cheers,
>>>> Guillaume Nodet
>>>> ------------------------
>>>> Blog: http://gnodet.blogspot.com/
>>>> ------------------------
>>>> Open Source SOA
>>>> http://fusesource.com
>>>>
>>>>
>>>
>>>
>>> --
>>> Karl Pauls
>>> karlpauls@gmail.com
>>>
>>>
>>
>>
>>
>



--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com



-- 
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Re: [all] OSGI - POOL-160

Posted by Guillaume Nodet <gn...@gmail.com>.
I think I'll foward this discussion back to their dev list and things
should be ok I suppose.

On Thu, Feb 25, 2010 at 17:44, Richard S. Hall <he...@ungoverned.org> wrote:
> On 2/26/10 12:40 AM, Guillaume Nodet wrote:
>>
>> It does not seem to be sufficient to the commons guys as the want an
>> "official" and expert blessing from the felix community because it
>> kinda contradicts the earlier statement they had from Peter which said
>> that importing your exported packages is a best practice in osgi.
>>
>
> Well, they should have talked to us. ;-)
>
> Seriously, what more can we say? The FAQ has existed for a fairly long time
> and our story hasn't changed. Are you suggesting that we need to change the
> FAQ in some way? Or are you saying that you want some official OSGi Alliance
> statement on this?
>
> As it stands, I think the FAQ tries to explain the issues for deciding what
> you should do fairly well, but we're willing to improve it if it is not
> clear.
>
> -> richard
>
>> On Thu, Feb 25, 2010 at 17:23, Karl Pauls<ka...@gmail.com>  wrote:
>>
>>>
>>> On Thu, Feb 25, 2010 at 5:17 PM, Guillaume Nodet<gn...@gmail.com>
>>>  wrote:
>>>
>>>>
>>>> What is the best practices for libraries wrt to importing their own
>>>> exported packages.
>>>>
>>>
>>> Well, I still don't know what you want to discuss. We have this in the
>>> FAQ:
>>>
>>> The main time you want to export only, is if your bundle is purely a
>>> library bundle, then its packages will only be used if they are
>>> needed. Another case might be if you have tightly coupled bundles
>>> sharing implementation packages. However, if your bundle will be
>>> started and especially if the exported packages define service
>>> interfaces or are referenced from service interfaces, then you will
>>> generally want to export and import them.
>>>
>>> which seems to be good and is what seems to be not followed in the
>>> below use case - which causes a problem. If commons pool wouldn't
>>> import what it exports then everything would have been fine no?
>>>
>>> Obviously, there is now single answer to this problem but the FAQ
>>> seems correct to me. I guess I'm still missing the point.
>>>
>>> regards,
>>>
>>> Karl
>>>
>>>
>>>>
>>>> On Thu, Feb 25, 2010 at 17:15, Karl Pauls<ka...@gmail.com>  wrote:
>>>>
>>>>>
>>>>> On Thu, Feb 25, 2010 at 5:11 PM, Guillaume Nodet<gn...@gmail.com>
>>>>>  wrote:
>>>>>
>>>>>>
>>>>>> Guys, can we discuss that and come back with a statement we all agree
>>>>>> on ?
>>>>>>
>>>>>
>>>>> Discuss what?
>>>>>
>>>>> regards,
>>>>>
>>>>> Karl
>>>>>
>>>>>
>>>>>>
>>>>>> ---------- Forwarded message ----------
>>>>>> From: Niall Pemberton<ni...@gmail.com>
>>>>>> Date: Thu, Feb 25, 2010 at 16:26
>>>>>> Subject: Re: [all] OSGI - POOL-160
>>>>>> To: Commons Developers List<de...@commons.apache.org>
>>>>>>
>>>>>>
>>>>>> On Thu, Feb 25, 2010 at 3:17 PM, Jörg Schaible<jo...@gmx.de>
>>>>>>  wrote:
>>>>>>
>>>>>>>
>>>>>>> Hi Guillaime,
>>>>>>>
>>>>>>> Guillaume Nodet wrote at Donnerstag, 25. Februar 2010 15:49:
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> I just had a lively chat with Peter who kinda agreed that
>>>>>>>> substitutability issue is mostly important for APIs.
>>>>>>>>
>>>>>>>> Please have a look at the Felix FAQ entry:
>>>>>>>>   http://felix.apache.org/site/apache-felix-osgi-
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> faq.html#ApacheFelixOSGiFAQ-Shouldabundleimportitsownexportedpackages%253F
>>>>>>>
>>>>>>>>
>>>>>>>> I haven't written it, so I can't be blame for that one.
>>>>>>>> The last paragraph says:
>>>>>>>>     "The main time you want to export only, is if your bundle is
>>>>>>>> purely a library bundle, then its packages will only be used if they
>>>>>>>> are needed."
>>>>>>>>
>>>>>>>
>>>>>>> what we are saying is, that none of us is an OSGi expert and before
>>>>>>> we
>>>>>>> published the first artifact with such information, we took the
>>>>>>> advice of
>>>>>>> the Apache Felix community. If they recommend now something
>>>>>>> different, we'd
>>>>>>> like to get some "official" blessing for the changes, simply because
>>>>>>> we
>>>>>>> cannot really review it.
>>>>>>>
>>>>>>
>>>>>> +1
>>>>>>
>>>>>> Niall
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>
>>>>>>>> In all cases, the current imports *are* wrong and need to be fixed,
>>>>>>>> because the way they are written will fail if there is any
>>>>>>>> incompatible change ever introduced (whatever the version).  And I
>>>>>>>> don't think we should guarantee that, especially across major
>>>>>>>> versions.
>>>>>>>>
>>>>>>>
>>>>>>> What has been released is final. We're not able to change that
>>>>>>> anymore. All
>>>>>>> we can do is to change the OSGi information for new releases.
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> Anyway, the problem is the following.
>>>>>>>> You install commons-pool 1.5 in the osgi framework.
>>>>>>>> Then you install commons-pool 1.4 later.
>>>>>>>> What you end up with is:
>>>>>>>>
>>>>>>>> karaf@root>  osgi:list -l | grep commons-pool
>>>>>>>> [ 100] [Active     ] [            ] [       ] [   60]
>>>>>>>> mvn:commons-pool/commons-pool/1.5.4
>>>>>>>> [ 124] [Active     ] [            ] [       ] [   60]
>>>>>>>> mvn:commons-pool/commons-pool/1.4
>>>>>>>> karaf@root>  packages:exports 100
>>>>>>>> Commons Pool (100): org.apache.commons.pool.impl; version=1.5.4
>>>>>>>> Commons Pool (100): org.apache.commons.pool; version=1.5.4
>>>>>>>> karaf@root>  packages:exports 124
>>>>>>>> Apache Commons Pool Bundle (124): No active exported packages.
>>>>>>>> karaf@root>  packages:imports 124
>>>>>>>> Commons Pool (100): org.apache.commons.pool.impl; version=1.5.4
>>>>>>>> Commons Pool (100): org.apache.commons.pool; version=1.5.4
>>>>>>>> karaf@root>  osgi:start 170
>>>>>>>> Error executing command: Unresolved constraint in bundle
>>>>>>>> org.apache.activemq.activemq-pool [129]: package;
>>>>>>>> (&(package=org.apache.commons.pool.impl)(version>=1.4.0)(!
>>>>>>>>
>>>>>>>
>>>>>>> (version>=1.5.0)))
>>>>>>>
>>>>>>> While I see an error, it does not tell me a lot ;-)
>>>>>>>
>>>>>>> - Jörg
>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Cheers,
>>>>>> Guillaume Nodet
>>>>>> ------------------------
>>>>>> Blog: http://gnodet.blogspot.com/
>>>>>> ------------------------
>>>>>> Open Source SOA
>>>>>> http://fusesource.com
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Karl Pauls
>>>>> karlpauls@gmail.com
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Cheers,
>>>> Guillaume Nodet
>>>> ------------------------
>>>> Blog: http://gnodet.blogspot.com/
>>>> ------------------------
>>>> Open Source SOA
>>>> http://fusesource.com
>>>>
>>>>
>>>
>>>
>>> --
>>> Karl Pauls
>>> karlpauls@gmail.com
>>>
>>>
>>
>>
>>
>



-- 
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com

Re: [all] OSGI - POOL-160

Posted by Niall Pemberton <ni...@gmail.com>.
On Fri, Feb 26, 2010 at 3:27 AM, Richard S. Hall <he...@ungoverned.org> wrote:
> On 2/26/10 7:43 AM, Niall Pemberton wrote:
>>
>> On Thu, Feb 25, 2010 at 4:44 PM, Richard S. Hall<he...@ungoverned.org>
>>  wrote:
>>
>>>
>>> On 2/26/10 12:40 AM, Guillaume Nodet wrote:
>>>
>>>>
>>>> It does not seem to be sufficient to the commons guys as the want an
>>>> "official" and expert blessing from the felix community because it
>>>> kinda contradicts the earlier statement they had from Peter which said
>>>> that importing your exported packages is a best practice in osgi.
>>>>
>>>>
>>>
>>> Well, they should have talked to us. ;-)
>>>
>>
>> It came up in three separate threads, here and there was consistently
>> the same message :(
>>
>
> Sorry for being flippant.
>
>> http://felix.markmail.org/message/qp33zosdp43e2vnv
>> http://felix.markmail.org/message/tczwuc4qfdo3kpey
>> http://felix.markmail.org/message/4y6s7eqdsg5nirvg
>> http://felix.markmail.org/message/lg7w4qtetfvhncte
>>
>
> I admit, no one said anything to the contrary in these threads. I am not
> sure why I didn't respond to the issue at all. Not sure when the FAQ was
> created in relation...looks like it was created in April 2008, so perhaps it
> was in response to these questions on the list.
>
>>> Seriously, what more can we say?
>>>
>>
>> We asked for confirmation from you guys because it had come up several
>> times and was the opposite of the advice we had been given here.
>>
>
> Clearly, this wasn't the best advice at the time even though we apparently
> knew which advice to give as witnessed by the FAQ from around the same time.
> The difficulty is that there often is no single answer, so you often end up
> with the default "best practice" as opposed to the best practice tailored to
> your specific scenario.
>
> Sorry we weren't onl the ball back then to give the most appropriate
> recommendation, but at this point going forward I'd follow the advice of the
> FAQ and if it isn't clear or you have questions, let us know and we'll try
> to do a better job at steering you in the correct direction this time.

OK thanks

Niall

> -> richard
>
>
>> Niall
>>
>>
>>>
>>> The FAQ has existed for a fairly long time
>>> and our story hasn't changed. Are you suggesting that we need to change
>>> the
>>> FAQ in some way? Or are you saying that you want some official OSGi
>>> Alliance
>>> statement on this?
>>>
>>> As it stands, I think the FAQ tries to explain the issues for deciding
>>> what
>>> you should do fairly well, but we're willing to improve it if it is not
>>> clear.
>>>
>>> ->  richard
>>>
>>>
>>>>
>>>> On Thu, Feb 25, 2010 at 17:23, Karl Pauls<ka...@gmail.com>    wrote:
>>>>
>>>>
>>>>>
>>>>> On Thu, Feb 25, 2010 at 5:17 PM, Guillaume Nodet<gn...@gmail.com>
>>>>>  wrote:
>>>>>
>>>>>
>>>>>>
>>>>>> What is the best practices for libraries wrt to importing their own
>>>>>> exported packages.
>>>>>>
>>>>>>
>>>>>
>>>>> Well, I still don't know what you want to discuss. We have this in the
>>>>> FAQ:
>>>>>
>>>>> The main time you want to export only, is if your bundle is purely a
>>>>> library bundle, then its packages will only be used if they are
>>>>> needed. Another case might be if you have tightly coupled bundles
>>>>> sharing implementation packages. However, if your bundle will be
>>>>> started and especially if the exported packages define service
>>>>> interfaces or are referenced from service interfaces, then you will
>>>>> generally want to export and import them.
>>>>>
>>>>> which seems to be good and is what seems to be not followed in the
>>>>> below use case - which causes a problem. If commons pool wouldn't
>>>>> import what it exports then everything would have been fine no?
>>>>>
>>>>> Obviously, there is now single answer to this problem but the FAQ
>>>>> seems correct to me. I guess I'm still missing the point.
>>>>>
>>>>> regards,
>>>>>
>>>>> Karl
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>> On Thu, Feb 25, 2010 at 17:15, Karl Pauls<ka...@gmail.com>
>>>>>>  wrote:
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> On Thu, Feb 25, 2010 at 5:11 PM, Guillaume Nodet<gn...@gmail.com>
>>>>>>>  wrote:
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> Guys, can we discuss that and come back with a statement we all
>>>>>>>> agree
>>>>>>>> on ?
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> Discuss what?
>>>>>>>
>>>>>>> regards,
>>>>>>>
>>>>>>> Karl
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> ---------- Forwarded message ----------
>>>>>>>> From: Niall Pemberton<ni...@gmail.com>
>>>>>>>> Date: Thu, Feb 25, 2010 at 16:26
>>>>>>>> Subject: Re: [all] OSGI - POOL-160
>>>>>>>> To: Commons Developers List<de...@commons.apache.org>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Thu, Feb 25, 2010 at 3:17 PM, Jörg
>>>>>>>> Schaible<jo...@gmx.de>
>>>>>>>>  wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Hi Guillaime,
>>>>>>>>>
>>>>>>>>> Guillaume Nodet wrote at Donnerstag, 25. Februar 2010 15:49:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I just had a lively chat with Peter who kinda agreed that
>>>>>>>>>> substitutability issue is mostly important for APIs.
>>>>>>>>>>
>>>>>>>>>> Please have a look at the Felix FAQ entry:
>>>>>>>>>>   http://felix.apache.org/site/apache-felix-osgi-
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> faq.html#ApacheFelixOSGiFAQ-Shouldabundleimportitsownexportedpackages%253F
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I haven't written it, so I can't be blame for that one.
>>>>>>>>>> The last paragraph says:
>>>>>>>>>>     "The main time you want to export only, is if your bundle is
>>>>>>>>>> purely a library bundle, then its packages will only be used if
>>>>>>>>>> they
>>>>>>>>>> are needed."
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> what we are saying is, that none of us is an OSGi expert and before
>>>>>>>>> we
>>>>>>>>> published the first artifact with such information, we took the
>>>>>>>>> advice of
>>>>>>>>> the Apache Felix community. If they recommend now something
>>>>>>>>> different, we'd
>>>>>>>>> like to get some "official" blessing for the changes, simply
>>>>>>>>> because
>>>>>>>>> we
>>>>>>>>> cannot really review it.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> +1
>>>>>>>>
>>>>>>>> Niall
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> In all cases, the current imports *are* wrong and need to be
>>>>>>>>>> fixed,
>>>>>>>>>> because the way they are written will fail if there is any
>>>>>>>>>> incompatible change ever introduced (whatever the version).  And I
>>>>>>>>>> don't think we should guarantee that, especially across major
>>>>>>>>>> versions.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> What has been released is final. We're not able to change that
>>>>>>>>> anymore. All
>>>>>>>>> we can do is to change the OSGi information for new releases.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Anyway, the problem is the following.
>>>>>>>>>> You install commons-pool 1.5 in the osgi framework.
>>>>>>>>>> Then you install commons-pool 1.4 later.
>>>>>>>>>> What you end up with is:
>>>>>>>>>>
>>>>>>>>>> karaf@root>    osgi:list -l | grep commons-pool
>>>>>>>>>> [ 100] [Active     ] [            ] [       ] [   60]
>>>>>>>>>> mvn:commons-pool/commons-pool/1.5.4
>>>>>>>>>> [ 124] [Active     ] [            ] [       ] [   60]
>>>>>>>>>> mvn:commons-pool/commons-pool/1.4
>>>>>>>>>> karaf@root>    packages:exports 100
>>>>>>>>>> Commons Pool (100): org.apache.commons.pool.impl; version=1.5.4
>>>>>>>>>> Commons Pool (100): org.apache.commons.pool; version=1.5.4
>>>>>>>>>> karaf@root>    packages:exports 124
>>>>>>>>>> Apache Commons Pool Bundle (124): No active exported packages.
>>>>>>>>>> karaf@root>    packages:imports 124
>>>>>>>>>> Commons Pool (100): org.apache.commons.pool.impl; version=1.5.4
>>>>>>>>>> Commons Pool (100): org.apache.commons.pool; version=1.5.4
>>>>>>>>>> karaf@root>    osgi:start 170
>>>>>>>>>> Error executing command: Unresolved constraint in bundle
>>>>>>>>>> org.apache.activemq.activemq-pool [129]: package;
>>>>>>>>>> (&(package=org.apache.commons.pool.impl)(version>=1.4.0)(!
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> (version>=1.5.0)))
>>>>>>>>>
>>>>>>>>> While I see an error, it does not tell me a lot ;-)
>>>>>>>>>
>>>>>>>>> - Jörg
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Cheers,
>>>>>>>> Guillaume Nodet
>>>>>>>> ------------------------
>>>>>>>> Blog: http://gnodet.blogspot.com/
>>>>>>>> ------------------------
>>>>>>>> Open Source SOA
>>>>>>>> http://fusesource.com
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Karl Pauls
>>>>>>> karlpauls@gmail.com
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> Cheers,
>>>>>> Guillaume Nodet
>>>>>> ------------------------
>>>>>> Blog: http://gnodet.blogspot.com/
>>>>>> ------------------------
>>>>>> Open Source SOA
>>>>>> http://fusesource.com
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> Karl Pauls
>>>>> karlpauls@gmail.com
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>

Re: [all] OSGI - POOL-160

Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 2/26/10 7:43 AM, Niall Pemberton wrote:
> On Thu, Feb 25, 2010 at 4:44 PM, Richard S. Hall<he...@ungoverned.org>  wrote:
>    
>> On 2/26/10 12:40 AM, Guillaume Nodet wrote:
>>      
>>> It does not seem to be sufficient to the commons guys as the want an
>>> "official" and expert blessing from the felix community because it
>>> kinda contradicts the earlier statement they had from Peter which said
>>> that importing your exported packages is a best practice in osgi.
>>>
>>>        
>> Well, they should have talked to us. ;-)
>>      
> It came up in three separate threads, here and there was consistently
> the same message :(
>    

Sorry for being flippant.

> http://felix.markmail.org/message/qp33zosdp43e2vnv
> http://felix.markmail.org/message/tczwuc4qfdo3kpey
> http://felix.markmail.org/message/4y6s7eqdsg5nirvg
> http://felix.markmail.org/message/lg7w4qtetfvhncte
>    

I admit, no one said anything to the contrary in these threads. I am not 
sure why I didn't respond to the issue at all. Not sure when the FAQ was 
created in relation...looks like it was created in April 2008, so 
perhaps it was in response to these questions on the list.

>> Seriously, what more can we say?
>>      
> We asked for confirmation from you guys because it had come up several
> times and was the opposite of the advice we had been given here.
>    

Clearly, this wasn't the best advice at the time even though we 
apparently knew which advice to give as witnessed by the FAQ from around 
the same time. The difficulty is that there often is no single answer, 
so you often end up with the default "best practice" as opposed to the 
best practice tailored to your specific scenario.

Sorry we weren't onl the ball back then to give the most appropriate 
recommendation, but at this point going forward I'd follow the advice of 
the FAQ and if it isn't clear or you have questions, let us know and 
we'll try to do a better job at steering you in the correct direction 
this time.

-> richard


> Niall
>
>    
>> The FAQ has existed for a fairly long time
>> and our story hasn't changed. Are you suggesting that we need to change the
>> FAQ in some way? Or are you saying that you want some official OSGi Alliance
>> statement on this?
>>
>> As it stands, I think the FAQ tries to explain the issues for deciding what
>> you should do fairly well, but we're willing to improve it if it is not
>> clear.
>>
>> ->  richard
>>
>>      
>>> On Thu, Feb 25, 2010 at 17:23, Karl Pauls<ka...@gmail.com>    wrote:
>>>
>>>        
>>>> On Thu, Feb 25, 2010 at 5:17 PM, Guillaume Nodet<gn...@gmail.com>
>>>>   wrote:
>>>>
>>>>          
>>>>> What is the best practices for libraries wrt to importing their own
>>>>> exported packages.
>>>>>
>>>>>            
>>>> Well, I still don't know what you want to discuss. We have this in the
>>>> FAQ:
>>>>
>>>> The main time you want to export only, is if your bundle is purely a
>>>> library bundle, then its packages will only be used if they are
>>>> needed. Another case might be if you have tightly coupled bundles
>>>> sharing implementation packages. However, if your bundle will be
>>>> started and especially if the exported packages define service
>>>> interfaces or are referenced from service interfaces, then you will
>>>> generally want to export and import them.
>>>>
>>>> which seems to be good and is what seems to be not followed in the
>>>> below use case - which causes a problem. If commons pool wouldn't
>>>> import what it exports then everything would have been fine no?
>>>>
>>>> Obviously, there is now single answer to this problem but the FAQ
>>>> seems correct to me. I guess I'm still missing the point.
>>>>
>>>> regards,
>>>>
>>>> Karl
>>>>
>>>>
>>>>          
>>>>> On Thu, Feb 25, 2010 at 17:15, Karl Pauls<ka...@gmail.com>    wrote:
>>>>>
>>>>>            
>>>>>> On Thu, Feb 25, 2010 at 5:11 PM, Guillaume Nodet<gn...@gmail.com>
>>>>>>   wrote:
>>>>>>
>>>>>>              
>>>>>>> Guys, can we discuss that and come back with a statement we all agree
>>>>>>> on ?
>>>>>>>
>>>>>>>                
>>>>>> Discuss what?
>>>>>>
>>>>>> regards,
>>>>>>
>>>>>> Karl
>>>>>>
>>>>>>
>>>>>>              
>>>>>>> ---------- Forwarded message ----------
>>>>>>> From: Niall Pemberton<ni...@gmail.com>
>>>>>>> Date: Thu, Feb 25, 2010 at 16:26
>>>>>>> Subject: Re: [all] OSGI - POOL-160
>>>>>>> To: Commons Developers List<de...@commons.apache.org>
>>>>>>>
>>>>>>>
>>>>>>> On Thu, Feb 25, 2010 at 3:17 PM, Jörg Schaible<jo...@gmx.de>
>>>>>>>   wrote:
>>>>>>>
>>>>>>>                
>>>>>>>> Hi Guillaime,
>>>>>>>>
>>>>>>>> Guillaume Nodet wrote at Donnerstag, 25. Februar 2010 15:49:
>>>>>>>>
>>>>>>>>
>>>>>>>>                  
>>>>>>>>> I just had a lively chat with Peter who kinda agreed that
>>>>>>>>> substitutability issue is mostly important for APIs.
>>>>>>>>>
>>>>>>>>> Please have a look at the Felix FAQ entry:
>>>>>>>>>    http://felix.apache.org/site/apache-felix-osgi-
>>>>>>>>>
>>>>>>>>>                    
>>>>>>>>
>>>>>>>> faq.html#ApacheFelixOSGiFAQ-Shouldabundleimportitsownexportedpackages%253F
>>>>>>>>
>>>>>>>>                  
>>>>>>>>> I haven't written it, so I can't be blame for that one.
>>>>>>>>> The last paragraph says:
>>>>>>>>>      "The main time you want to export only, is if your bundle is
>>>>>>>>> purely a library bundle, then its packages will only be used if they
>>>>>>>>> are needed."
>>>>>>>>>
>>>>>>>>>                    
>>>>>>>> what we are saying is, that none of us is an OSGi expert and before
>>>>>>>> we
>>>>>>>> published the first artifact with such information, we took the
>>>>>>>> advice of
>>>>>>>> the Apache Felix community. If they recommend now something
>>>>>>>> different, we'd
>>>>>>>> like to get some "official" blessing for the changes, simply because
>>>>>>>> we
>>>>>>>> cannot really review it.
>>>>>>>>
>>>>>>>>                  
>>>>>>> +1
>>>>>>>
>>>>>>> Niall
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>                
>>>>>>>>> In all cases, the current imports *are* wrong and need to be fixed,
>>>>>>>>> because the way they are written will fail if there is any
>>>>>>>>> incompatible change ever introduced (whatever the version).  And I
>>>>>>>>> don't think we should guarantee that, especially across major
>>>>>>>>> versions.
>>>>>>>>>
>>>>>>>>>                    
>>>>>>>> What has been released is final. We're not able to change that
>>>>>>>> anymore. All
>>>>>>>> we can do is to change the OSGi information for new releases.
>>>>>>>>
>>>>>>>>
>>>>>>>>                  
>>>>>>>>> Anyway, the problem is the following.
>>>>>>>>> You install commons-pool 1.5 in the osgi framework.
>>>>>>>>> Then you install commons-pool 1.4 later.
>>>>>>>>> What you end up with is:
>>>>>>>>>
>>>>>>>>> karaf@root>    osgi:list -l | grep commons-pool
>>>>>>>>> [ 100] [Active     ] [            ] [       ] [   60]
>>>>>>>>> mvn:commons-pool/commons-pool/1.5.4
>>>>>>>>> [ 124] [Active     ] [            ] [       ] [   60]
>>>>>>>>> mvn:commons-pool/commons-pool/1.4
>>>>>>>>> karaf@root>    packages:exports 100
>>>>>>>>> Commons Pool (100): org.apache.commons.pool.impl; version=1.5.4
>>>>>>>>> Commons Pool (100): org.apache.commons.pool; version=1.5.4
>>>>>>>>> karaf@root>    packages:exports 124
>>>>>>>>> Apache Commons Pool Bundle (124): No active exported packages.
>>>>>>>>> karaf@root>    packages:imports 124
>>>>>>>>> Commons Pool (100): org.apache.commons.pool.impl; version=1.5.4
>>>>>>>>> Commons Pool (100): org.apache.commons.pool; version=1.5.4
>>>>>>>>> karaf@root>    osgi:start 170
>>>>>>>>> Error executing command: Unresolved constraint in bundle
>>>>>>>>> org.apache.activemq.activemq-pool [129]: package;
>>>>>>>>> (&(package=org.apache.commons.pool.impl)(version>=1.4.0)(!
>>>>>>>>>
>>>>>>>>>                    
>>>>>>>> (version>=1.5.0)))
>>>>>>>>
>>>>>>>> While I see an error, it does not tell me a lot ;-)
>>>>>>>>
>>>>>>>> - Jörg
>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>                  
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Cheers,
>>>>>>> Guillaume Nodet
>>>>>>> ------------------------
>>>>>>> Blog: http://gnodet.blogspot.com/
>>>>>>> ------------------------
>>>>>>> Open Source SOA
>>>>>>> http://fusesource.com
>>>>>>>
>>>>>>>
>>>>>>>                
>>>>>>
>>>>>> --
>>>>>> Karl Pauls
>>>>>> karlpauls@gmail.com
>>>>>>
>>>>>>
>>>>>>              
>>>>>
>>>>> --
>>>>> Cheers,
>>>>> Guillaume Nodet
>>>>> ------------------------
>>>>> Blog: http://gnodet.blogspot.com/
>>>>> ------------------------
>>>>> Open Source SOA
>>>>> http://fusesource.com
>>>>>
>>>>>
>>>>>            
>>>>
>>>> --
>>>> Karl Pauls
>>>> karlpauls@gmail.com
>>>>
>>>>
>>>>          
>>>
>>>
>>>        
>>      

Re: [all] OSGI - POOL-160

Posted by Niall Pemberton <ni...@gmail.com>.
On Thu, Feb 25, 2010 at 4:44 PM, Richard S. Hall <he...@ungoverned.org> wrote:
> On 2/26/10 12:40 AM, Guillaume Nodet wrote:
>>
>> It does not seem to be sufficient to the commons guys as the want an
>> "official" and expert blessing from the felix community because it
>> kinda contradicts the earlier statement they had from Peter which said
>> that importing your exported packages is a best practice in osgi.
>>
>
> Well, they should have talked to us. ;-)

It came up in three separate threads, here and there was consistently
the same message :(

http://felix.markmail.org/message/qp33zosdp43e2vnv
http://felix.markmail.org/message/tczwuc4qfdo3kpey
http://felix.markmail.org/message/4y6s7eqdsg5nirvg
http://felix.markmail.org/message/lg7w4qtetfvhncte

> Seriously, what more can we say?

We asked for confirmation from you guys because it had come up several
times and was the opposite of the advice we had been given here.

Niall

> The FAQ has existed for a fairly long time
> and our story hasn't changed. Are you suggesting that we need to change the
> FAQ in some way? Or are you saying that you want some official OSGi Alliance
> statement on this?
>
> As it stands, I think the FAQ tries to explain the issues for deciding what
> you should do fairly well, but we're willing to improve it if it is not
> clear.
>
> -> richard
>
>> On Thu, Feb 25, 2010 at 17:23, Karl Pauls<ka...@gmail.com>  wrote:
>>
>>>
>>> On Thu, Feb 25, 2010 at 5:17 PM, Guillaume Nodet<gn...@gmail.com>
>>>  wrote:
>>>
>>>>
>>>> What is the best practices for libraries wrt to importing their own
>>>> exported packages.
>>>>
>>>
>>> Well, I still don't know what you want to discuss. We have this in the
>>> FAQ:
>>>
>>> The main time you want to export only, is if your bundle is purely a
>>> library bundle, then its packages will only be used if they are
>>> needed. Another case might be if you have tightly coupled bundles
>>> sharing implementation packages. However, if your bundle will be
>>> started and especially if the exported packages define service
>>> interfaces or are referenced from service interfaces, then you will
>>> generally want to export and import them.
>>>
>>> which seems to be good and is what seems to be not followed in the
>>> below use case - which causes a problem. If commons pool wouldn't
>>> import what it exports then everything would have been fine no?
>>>
>>> Obviously, there is now single answer to this problem but the FAQ
>>> seems correct to me. I guess I'm still missing the point.
>>>
>>> regards,
>>>
>>> Karl
>>>
>>>
>>>>
>>>> On Thu, Feb 25, 2010 at 17:15, Karl Pauls<ka...@gmail.com>  wrote:
>>>>
>>>>>
>>>>> On Thu, Feb 25, 2010 at 5:11 PM, Guillaume Nodet<gn...@gmail.com>
>>>>>  wrote:
>>>>>
>>>>>>
>>>>>> Guys, can we discuss that and come back with a statement we all agree
>>>>>> on ?
>>>>>>
>>>>>
>>>>> Discuss what?
>>>>>
>>>>> regards,
>>>>>
>>>>> Karl
>>>>>
>>>>>
>>>>>>
>>>>>> ---------- Forwarded message ----------
>>>>>> From: Niall Pemberton<ni...@gmail.com>
>>>>>> Date: Thu, Feb 25, 2010 at 16:26
>>>>>> Subject: Re: [all] OSGI - POOL-160
>>>>>> To: Commons Developers List<de...@commons.apache.org>
>>>>>>
>>>>>>
>>>>>> On Thu, Feb 25, 2010 at 3:17 PM, Jörg Schaible<jo...@gmx.de>
>>>>>>  wrote:
>>>>>>
>>>>>>>
>>>>>>> Hi Guillaime,
>>>>>>>
>>>>>>> Guillaume Nodet wrote at Donnerstag, 25. Februar 2010 15:49:
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> I just had a lively chat with Peter who kinda agreed that
>>>>>>>> substitutability issue is mostly important for APIs.
>>>>>>>>
>>>>>>>> Please have a look at the Felix FAQ entry:
>>>>>>>>   http://felix.apache.org/site/apache-felix-osgi-
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> faq.html#ApacheFelixOSGiFAQ-Shouldabundleimportitsownexportedpackages%253F
>>>>>>>
>>>>>>>>
>>>>>>>> I haven't written it, so I can't be blame for that one.
>>>>>>>> The last paragraph says:
>>>>>>>>     "The main time you want to export only, is if your bundle is
>>>>>>>> purely a library bundle, then its packages will only be used if they
>>>>>>>> are needed."
>>>>>>>>
>>>>>>>
>>>>>>> what we are saying is, that none of us is an OSGi expert and before
>>>>>>> we
>>>>>>> published the first artifact with such information, we took the
>>>>>>> advice of
>>>>>>> the Apache Felix community. If they recommend now something
>>>>>>> different, we'd
>>>>>>> like to get some "official" blessing for the changes, simply because
>>>>>>> we
>>>>>>> cannot really review it.
>>>>>>>
>>>>>>
>>>>>> +1
>>>>>>
>>>>>> Niall
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>
>>>>>>>> In all cases, the current imports *are* wrong and need to be fixed,
>>>>>>>> because the way they are written will fail if there is any
>>>>>>>> incompatible change ever introduced (whatever the version).  And I
>>>>>>>> don't think we should guarantee that, especially across major
>>>>>>>> versions.
>>>>>>>>
>>>>>>>
>>>>>>> What has been released is final. We're not able to change that
>>>>>>> anymore. All
>>>>>>> we can do is to change the OSGi information for new releases.
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> Anyway, the problem is the following.
>>>>>>>> You install commons-pool 1.5 in the osgi framework.
>>>>>>>> Then you install commons-pool 1.4 later.
>>>>>>>> What you end up with is:
>>>>>>>>
>>>>>>>> karaf@root>  osgi:list -l | grep commons-pool
>>>>>>>> [ 100] [Active     ] [            ] [       ] [   60]
>>>>>>>> mvn:commons-pool/commons-pool/1.5.4
>>>>>>>> [ 124] [Active     ] [            ] [       ] [   60]
>>>>>>>> mvn:commons-pool/commons-pool/1.4
>>>>>>>> karaf@root>  packages:exports 100
>>>>>>>> Commons Pool (100): org.apache.commons.pool.impl; version=1.5.4
>>>>>>>> Commons Pool (100): org.apache.commons.pool; version=1.5.4
>>>>>>>> karaf@root>  packages:exports 124
>>>>>>>> Apache Commons Pool Bundle (124): No active exported packages.
>>>>>>>> karaf@root>  packages:imports 124
>>>>>>>> Commons Pool (100): org.apache.commons.pool.impl; version=1.5.4
>>>>>>>> Commons Pool (100): org.apache.commons.pool; version=1.5.4
>>>>>>>> karaf@root>  osgi:start 170
>>>>>>>> Error executing command: Unresolved constraint in bundle
>>>>>>>> org.apache.activemq.activemq-pool [129]: package;
>>>>>>>> (&(package=org.apache.commons.pool.impl)(version>=1.4.0)(!
>>>>>>>>
>>>>>>>
>>>>>>> (version>=1.5.0)))
>>>>>>>
>>>>>>> While I see an error, it does not tell me a lot ;-)
>>>>>>>
>>>>>>> - Jörg
>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Cheers,
>>>>>> Guillaume Nodet
>>>>>> ------------------------
>>>>>> Blog: http://gnodet.blogspot.com/
>>>>>> ------------------------
>>>>>> Open Source SOA
>>>>>> http://fusesource.com
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Karl Pauls
>>>>> karlpauls@gmail.com
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Cheers,
>>>> Guillaume Nodet
>>>> ------------------------
>>>> Blog: http://gnodet.blogspot.com/
>>>> ------------------------
>>>> Open Source SOA
>>>> http://fusesource.com
>>>>
>>>>
>>>
>>>
>>> --
>>> Karl Pauls
>>> karlpauls@gmail.com
>>>
>>>
>>
>>
>>
>

Re: [all] OSGI - POOL-160

Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 2/26/10 12:40 AM, Guillaume Nodet wrote:
> It does not seem to be sufficient to the commons guys as the want an
> "official" and expert blessing from the felix community because it
> kinda contradicts the earlier statement they had from Peter which said
> that importing your exported packages is a best practice in osgi.
>    

Well, they should have talked to us. ;-)

Seriously, what more can we say? The FAQ has existed for a fairly long 
time and our story hasn't changed. Are you suggesting that we need to 
change the FAQ in some way? Or are you saying that you want some 
official OSGi Alliance statement on this?

As it stands, I think the FAQ tries to explain the issues for deciding 
what you should do fairly well, but we're willing to improve it if it is 
not clear.

-> richard

> On Thu, Feb 25, 2010 at 17:23, Karl Pauls<ka...@gmail.com>  wrote:
>    
>> On Thu, Feb 25, 2010 at 5:17 PM, Guillaume Nodet<gn...@gmail.com>  wrote:
>>      
>>> What is the best practices for libraries wrt to importing their own
>>> exported packages.
>>>        
>> Well, I still don't know what you want to discuss. We have this in the FAQ:
>>
>> The main time you want to export only, is if your bundle is purely a
>> library bundle, then its packages will only be used if they are
>> needed. Another case might be if you have tightly coupled bundles
>> sharing implementation packages. However, if your bundle will be
>> started and especially if the exported packages define service
>> interfaces or are referenced from service interfaces, then you will
>> generally want to export and import them.
>>
>> which seems to be good and is what seems to be not followed in the
>> below use case - which causes a problem. If commons pool wouldn't
>> import what it exports then everything would have been fine no?
>>
>> Obviously, there is now single answer to this problem but the FAQ
>> seems correct to me. I guess I'm still missing the point.
>>
>> regards,
>>
>> Karl
>>
>>      
>>> On Thu, Feb 25, 2010 at 17:15, Karl Pauls<ka...@gmail.com>  wrote:
>>>        
>>>> On Thu, Feb 25, 2010 at 5:11 PM, Guillaume Nodet<gn...@gmail.com>  wrote:
>>>>          
>>>>> Guys, can we discuss that and come back with a statement we all agree on ?
>>>>>            
>>>> Discuss what?
>>>>
>>>> regards,
>>>>
>>>> Karl
>>>>
>>>>          
>>>>> ---------- Forwarded message ----------
>>>>> From: Niall Pemberton<ni...@gmail.com>
>>>>> Date: Thu, Feb 25, 2010 at 16:26
>>>>> Subject: Re: [all] OSGI - POOL-160
>>>>> To: Commons Developers List<de...@commons.apache.org>
>>>>>
>>>>>
>>>>> On Thu, Feb 25, 2010 at 3:17 PM, Jörg Schaible<jo...@gmx.de>  wrote:
>>>>>            
>>>>>> Hi Guillaime,
>>>>>>
>>>>>> Guillaume Nodet wrote at Donnerstag, 25. Februar 2010 15:49:
>>>>>>
>>>>>>              
>>>>>>> I just had a lively chat with Peter who kinda agreed that
>>>>>>> substitutability issue is mostly important for APIs.
>>>>>>>
>>>>>>> Please have a look at the Felix FAQ entry:
>>>>>>>    http://felix.apache.org/site/apache-felix-osgi-
>>>>>>>                
>>>>>> faq.html#ApacheFelixOSGiFAQ-Shouldabundleimportitsownexportedpackages%253F
>>>>>>              
>>>>>>> I haven't written it, so I can't be blame for that one.
>>>>>>> The last paragraph says:
>>>>>>>      "The main time you want to export only, is if your bundle is
>>>>>>> purely a library bundle, then its packages will only be used if they
>>>>>>> are needed."
>>>>>>>                
>>>>>> what we are saying is, that none of us is an OSGi expert and before we
>>>>>> published the first artifact with such information, we took the advice of
>>>>>> the Apache Felix community. If they recommend now something different, we'd
>>>>>> like to get some "official" blessing for the changes, simply because we
>>>>>> cannot really review it.
>>>>>>              
>>>>> +1
>>>>>
>>>>> Niall
>>>>>
>>>>>
>>>>>            
>>>>>>> In all cases, the current imports *are* wrong and need to be fixed,
>>>>>>> because the way they are written will fail if there is any
>>>>>>> incompatible change ever introduced (whatever the version).  And I
>>>>>>> don't think we should guarantee that, especially across major
>>>>>>> versions.
>>>>>>>                
>>>>>> What has been released is final. We're not able to change that anymore. All
>>>>>> we can do is to change the OSGi information for new releases.
>>>>>>
>>>>>>              
>>>>>>> Anyway, the problem is the following.
>>>>>>> You install commons-pool 1.5 in the osgi framework.
>>>>>>> Then you install commons-pool 1.4 later.
>>>>>>> What you end up with is:
>>>>>>>
>>>>>>> karaf@root>  osgi:list -l | grep commons-pool
>>>>>>> [ 100] [Active     ] [            ] [       ] [   60]
>>>>>>> mvn:commons-pool/commons-pool/1.5.4
>>>>>>> [ 124] [Active     ] [            ] [       ] [   60]
>>>>>>> mvn:commons-pool/commons-pool/1.4
>>>>>>> karaf@root>  packages:exports 100
>>>>>>> Commons Pool (100): org.apache.commons.pool.impl; version=1.5.4
>>>>>>> Commons Pool (100): org.apache.commons.pool; version=1.5.4
>>>>>>> karaf@root>  packages:exports 124
>>>>>>> Apache Commons Pool Bundle (124): No active exported packages.
>>>>>>> karaf@root>  packages:imports 124
>>>>>>> Commons Pool (100): org.apache.commons.pool.impl; version=1.5.4
>>>>>>> Commons Pool (100): org.apache.commons.pool; version=1.5.4
>>>>>>> karaf@root>  osgi:start 170
>>>>>>> Error executing command: Unresolved constraint in bundle
>>>>>>> org.apache.activemq.activemq-pool [129]: package;
>>>>>>> (&(package=org.apache.commons.pool.impl)(version>=1.4.0)(!
>>>>>>>                
>>>>>> (version>=1.5.0)))
>>>>>>
>>>>>> While I see an error, it does not tell me a lot ;-)
>>>>>>
>>>>>> - Jörg
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>
>>>>>>
>>>>>>              
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Cheers,
>>>>> Guillaume Nodet
>>>>> ------------------------
>>>>> Blog: http://gnodet.blogspot.com/
>>>>> ------------------------
>>>>> Open Source SOA
>>>>> http://fusesource.com
>>>>>
>>>>>            
>>>>
>>>>
>>>> --
>>>> Karl Pauls
>>>> karlpauls@gmail.com
>>>>
>>>>          
>>>
>>>
>>> --
>>> Cheers,
>>> Guillaume Nodet
>>> ------------------------
>>> Blog: http://gnodet.blogspot.com/
>>> ------------------------
>>> Open Source SOA
>>> http://fusesource.com
>>>
>>>        
>>
>>
>> --
>> Karl Pauls
>> karlpauls@gmail.com
>>
>>      
>
>
>    

Re: [all] OSGI - POOL-160

Posted by Guillaume Nodet <gn...@gmail.com>.
It does not seem to be sufficient to the commons guys as the want an
"official" and expert blessing from the felix community because it
kinda contradicts the earlier statement they had from Peter which said
that importing your exported packages is a best practice in osgi.

On Thu, Feb 25, 2010 at 17:23, Karl Pauls <ka...@gmail.com> wrote:
> On Thu, Feb 25, 2010 at 5:17 PM, Guillaume Nodet <gn...@gmail.com> wrote:
>> What is the best practices for libraries wrt to importing their own
>> exported packages.
>
> Well, I still don't know what you want to discuss. We have this in the FAQ:
>
> The main time you want to export only, is if your bundle is purely a
> library bundle, then its packages will only be used if they are
> needed. Another case might be if you have tightly coupled bundles
> sharing implementation packages. However, if your bundle will be
> started and especially if the exported packages define service
> interfaces or are referenced from service interfaces, then you will
> generally want to export and import them.
>
> which seems to be good and is what seems to be not followed in the
> below use case - which causes a problem. If commons pool wouldn't
> import what it exports then everything would have been fine no?
>
> Obviously, there is now single answer to this problem but the FAQ
> seems correct to me. I guess I'm still missing the point.
>
> regards,
>
> Karl
>
>> On Thu, Feb 25, 2010 at 17:15, Karl Pauls <ka...@gmail.com> wrote:
>>> On Thu, Feb 25, 2010 at 5:11 PM, Guillaume Nodet <gn...@gmail.com> wrote:
>>>> Guys, can we discuss that and come back with a statement we all agree on ?
>>>
>>> Discuss what?
>>>
>>> regards,
>>>
>>> Karl
>>>
>>>> ---------- Forwarded message ----------
>>>> From: Niall Pemberton <ni...@gmail.com>
>>>> Date: Thu, Feb 25, 2010 at 16:26
>>>> Subject: Re: [all] OSGI - POOL-160
>>>> To: Commons Developers List <de...@commons.apache.org>
>>>>
>>>>
>>>> On Thu, Feb 25, 2010 at 3:17 PM, Jörg Schaible <jo...@gmx.de> wrote:
>>>>> Hi Guillaime,
>>>>>
>>>>> Guillaume Nodet wrote at Donnerstag, 25. Februar 2010 15:49:
>>>>>
>>>>>> I just had a lively chat with Peter who kinda agreed that
>>>>>> substitutability issue is mostly important for APIs.
>>>>>>
>>>>>> Please have a look at the Felix FAQ entry:
>>>>>>   http://felix.apache.org/site/apache-felix-osgi-
>>>>> faq.html#ApacheFelixOSGiFAQ-Shouldabundleimportitsownexportedpackages%253F
>>>>>> I haven't written it, so I can't be blame for that one.
>>>>>> The last paragraph says:
>>>>>>     "The main time you want to export only, is if your bundle is
>>>>>> purely a library bundle, then its packages will only be used if they
>>>>>> are needed."
>>>>>
>>>>> what we are saying is, that none of us is an OSGi expert and before we
>>>>> published the first artifact with such information, we took the advice of
>>>>> the Apache Felix community. If they recommend now something different, we'd
>>>>> like to get some "official" blessing for the changes, simply because we
>>>>> cannot really review it.
>>>>
>>>> +1
>>>>
>>>> Niall
>>>>
>>>>
>>>>>> In all cases, the current imports *are* wrong and need to be fixed,
>>>>>> because the way they are written will fail if there is any
>>>>>> incompatible change ever introduced (whatever the version).  And I
>>>>>> don't think we should guarantee that, especially across major
>>>>>> versions.
>>>>>
>>>>> What has been released is final. We're not able to change that anymore. All
>>>>> we can do is to change the OSGi information for new releases.
>>>>>
>>>>>> Anyway, the problem is the following.
>>>>>> You install commons-pool 1.5 in the osgi framework.
>>>>>> Then you install commons-pool 1.4 later.
>>>>>> What you end up with is:
>>>>>>
>>>>>> karaf@root> osgi:list -l | grep commons-pool
>>>>>> [ 100] [Active     ] [            ] [       ] [   60]
>>>>>> mvn:commons-pool/commons-pool/1.5.4
>>>>>> [ 124] [Active     ] [            ] [       ] [   60]
>>>>>> mvn:commons-pool/commons-pool/1.4
>>>>>> karaf@root> packages:exports 100
>>>>>> Commons Pool (100): org.apache.commons.pool.impl; version=1.5.4
>>>>>> Commons Pool (100): org.apache.commons.pool; version=1.5.4
>>>>>> karaf@root> packages:exports 124
>>>>>> Apache Commons Pool Bundle (124): No active exported packages.
>>>>>> karaf@root> packages:imports 124
>>>>>> Commons Pool (100): org.apache.commons.pool.impl; version=1.5.4
>>>>>> Commons Pool (100): org.apache.commons.pool; version=1.5.4
>>>>>> karaf@root> osgi:start 170
>>>>>> Error executing command: Unresolved constraint in bundle
>>>>>> org.apache.activemq.activemq-pool [129]: package;
>>>>>> (&(package=org.apache.commons.pool.impl)(version>=1.4.0)(!
>>>>> (version>=1.5.0)))
>>>>>
>>>>> While I see an error, it does not tell me a lot ;-)
>>>>>
>>>>> - Jörg
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Cheers,
>>>> Guillaume Nodet
>>>> ------------------------
>>>> Blog: http://gnodet.blogspot.com/
>>>> ------------------------
>>>> Open Source SOA
>>>> http://fusesource.com
>>>>
>>>
>>>
>>>
>>> --
>>> Karl Pauls
>>> karlpauls@gmail.com
>>>
>>
>>
>>
>> --
>> Cheers,
>> Guillaume Nodet
>> ------------------------
>> Blog: http://gnodet.blogspot.com/
>> ------------------------
>> Open Source SOA
>> http://fusesource.com
>>
>
>
>
> --
> Karl Pauls
> karlpauls@gmail.com
>



-- 
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com

Re: [all] OSGI - POOL-160

Posted by Karl Pauls <ka...@gmail.com>.
On Thu, Feb 25, 2010 at 5:17 PM, Guillaume Nodet <gn...@gmail.com> wrote:
> What is the best practices for libraries wrt to importing their own
> exported packages.

Well, I still don't know what you want to discuss. We have this in the FAQ:

The main time you want to export only, is if your bundle is purely a
library bundle, then its packages will only be used if they are
needed. Another case might be if you have tightly coupled bundles
sharing implementation packages. However, if your bundle will be
started and especially if the exported packages define service
interfaces or are referenced from service interfaces, then you will
generally want to export and import them.

which seems to be good and is what seems to be not followed in the
below use case - which causes a problem. If commons pool wouldn't
import what it exports then everything would have been fine no?

Obviously, there is now single answer to this problem but the FAQ
seems correct to me. I guess I'm still missing the point.

regards,

Karl

> On Thu, Feb 25, 2010 at 17:15, Karl Pauls <ka...@gmail.com> wrote:
>> On Thu, Feb 25, 2010 at 5:11 PM, Guillaume Nodet <gn...@gmail.com> wrote:
>>> Guys, can we discuss that and come back with a statement we all agree on ?
>>
>> Discuss what?
>>
>> regards,
>>
>> Karl
>>
>>> ---------- Forwarded message ----------
>>> From: Niall Pemberton <ni...@gmail.com>
>>> Date: Thu, Feb 25, 2010 at 16:26
>>> Subject: Re: [all] OSGI - POOL-160
>>> To: Commons Developers List <de...@commons.apache.org>
>>>
>>>
>>> On Thu, Feb 25, 2010 at 3:17 PM, Jörg Schaible <jo...@gmx.de> wrote:
>>>> Hi Guillaime,
>>>>
>>>> Guillaume Nodet wrote at Donnerstag, 25. Februar 2010 15:49:
>>>>
>>>>> I just had a lively chat with Peter who kinda agreed that
>>>>> substitutability issue is mostly important for APIs.
>>>>>
>>>>> Please have a look at the Felix FAQ entry:
>>>>>   http://felix.apache.org/site/apache-felix-osgi-
>>>> faq.html#ApacheFelixOSGiFAQ-Shouldabundleimportitsownexportedpackages%253F
>>>>> I haven't written it, so I can't be blame for that one.
>>>>> The last paragraph says:
>>>>>     "The main time you want to export only, is if your bundle is
>>>>> purely a library bundle, then its packages will only be used if they
>>>>> are needed."
>>>>
>>>> what we are saying is, that none of us is an OSGi expert and before we
>>>> published the first artifact with such information, we took the advice of
>>>> the Apache Felix community. If they recommend now something different, we'd
>>>> like to get some "official" blessing for the changes, simply because we
>>>> cannot really review it.
>>>
>>> +1
>>>
>>> Niall
>>>
>>>
>>>>> In all cases, the current imports *are* wrong and need to be fixed,
>>>>> because the way they are written will fail if there is any
>>>>> incompatible change ever introduced (whatever the version).  And I
>>>>> don't think we should guarantee that, especially across major
>>>>> versions.
>>>>
>>>> What has been released is final. We're not able to change that anymore. All
>>>> we can do is to change the OSGi information for new releases.
>>>>
>>>>> Anyway, the problem is the following.
>>>>> You install commons-pool 1.5 in the osgi framework.
>>>>> Then you install commons-pool 1.4 later.
>>>>> What you end up with is:
>>>>>
>>>>> karaf@root> osgi:list -l | grep commons-pool
>>>>> [ 100] [Active     ] [            ] [       ] [   60]
>>>>> mvn:commons-pool/commons-pool/1.5.4
>>>>> [ 124] [Active     ] [            ] [       ] [   60]
>>>>> mvn:commons-pool/commons-pool/1.4
>>>>> karaf@root> packages:exports 100
>>>>> Commons Pool (100): org.apache.commons.pool.impl; version=1.5.4
>>>>> Commons Pool (100): org.apache.commons.pool; version=1.5.4
>>>>> karaf@root> packages:exports 124
>>>>> Apache Commons Pool Bundle (124): No active exported packages.
>>>>> karaf@root> packages:imports 124
>>>>> Commons Pool (100): org.apache.commons.pool.impl; version=1.5.4
>>>>> Commons Pool (100): org.apache.commons.pool; version=1.5.4
>>>>> karaf@root> osgi:start 170
>>>>> Error executing command: Unresolved constraint in bundle
>>>>> org.apache.activemq.activemq-pool [129]: package;
>>>>> (&(package=org.apache.commons.pool.impl)(version>=1.4.0)(!
>>>> (version>=1.5.0)))
>>>>
>>>> While I see an error, it does not tell me a lot ;-)
>>>>
>>>> - Jörg
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>>
>>>
>>> --
>>> Cheers,
>>> Guillaume Nodet
>>> ------------------------
>>> Blog: http://gnodet.blogspot.com/
>>> ------------------------
>>> Open Source SOA
>>> http://fusesource.com
>>>
>>
>>
>>
>> --
>> Karl Pauls
>> karlpauls@gmail.com
>>
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
>



-- 
Karl Pauls
karlpauls@gmail.com

Re: [all] OSGI - POOL-160

Posted by Guillaume Nodet <gn...@gmail.com>.
What is the best practices for libraries wrt to importing their own
exported packages.

On Thu, Feb 25, 2010 at 17:15, Karl Pauls <ka...@gmail.com> wrote:
> On Thu, Feb 25, 2010 at 5:11 PM, Guillaume Nodet <gn...@gmail.com> wrote:
>> Guys, can we discuss that and come back with a statement we all agree on ?
>
> Discuss what?
>
> regards,
>
> Karl
>
>> ---------- Forwarded message ----------
>> From: Niall Pemberton <ni...@gmail.com>
>> Date: Thu, Feb 25, 2010 at 16:26
>> Subject: Re: [all] OSGI - POOL-160
>> To: Commons Developers List <de...@commons.apache.org>
>>
>>
>> On Thu, Feb 25, 2010 at 3:17 PM, Jörg Schaible <jo...@gmx.de> wrote:
>>> Hi Guillaime,
>>>
>>> Guillaume Nodet wrote at Donnerstag, 25. Februar 2010 15:49:
>>>
>>>> I just had a lively chat with Peter who kinda agreed that
>>>> substitutability issue is mostly important for APIs.
>>>>
>>>> Please have a look at the Felix FAQ entry:
>>>>   http://felix.apache.org/site/apache-felix-osgi-
>>> faq.html#ApacheFelixOSGiFAQ-Shouldabundleimportitsownexportedpackages%253F
>>>> I haven't written it, so I can't be blame for that one.
>>>> The last paragraph says:
>>>>     "The main time you want to export only, is if your bundle is
>>>> purely a library bundle, then its packages will only be used if they
>>>> are needed."
>>>
>>> what we are saying is, that none of us is an OSGi expert and before we
>>> published the first artifact with such information, we took the advice of
>>> the Apache Felix community. If they recommend now something different, we'd
>>> like to get some "official" blessing for the changes, simply because we
>>> cannot really review it.
>>
>> +1
>>
>> Niall
>>
>>
>>>> In all cases, the current imports *are* wrong and need to be fixed,
>>>> because the way they are written will fail if there is any
>>>> incompatible change ever introduced (whatever the version).  And I
>>>> don't think we should guarantee that, especially across major
>>>> versions.
>>>
>>> What has been released is final. We're not able to change that anymore. All
>>> we can do is to change the OSGi information for new releases.
>>>
>>>> Anyway, the problem is the following.
>>>> You install commons-pool 1.5 in the osgi framework.
>>>> Then you install commons-pool 1.4 later.
>>>> What you end up with is:
>>>>
>>>> karaf@root> osgi:list -l | grep commons-pool
>>>> [ 100] [Active     ] [            ] [       ] [   60]
>>>> mvn:commons-pool/commons-pool/1.5.4
>>>> [ 124] [Active     ] [            ] [       ] [   60]
>>>> mvn:commons-pool/commons-pool/1.4
>>>> karaf@root> packages:exports 100
>>>> Commons Pool (100): org.apache.commons.pool.impl; version=1.5.4
>>>> Commons Pool (100): org.apache.commons.pool; version=1.5.4
>>>> karaf@root> packages:exports 124
>>>> Apache Commons Pool Bundle (124): No active exported packages.
>>>> karaf@root> packages:imports 124
>>>> Commons Pool (100): org.apache.commons.pool.impl; version=1.5.4
>>>> Commons Pool (100): org.apache.commons.pool; version=1.5.4
>>>> karaf@root> osgi:start 170
>>>> Error executing command: Unresolved constraint in bundle
>>>> org.apache.activemq.activemq-pool [129]: package;
>>>> (&(package=org.apache.commons.pool.impl)(version>=1.4.0)(!
>>> (version>=1.5.0)))
>>>
>>> While I see an error, it does not tell me a lot ;-)
>>>
>>> - Jörg
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>>
>>
>> --
>> Cheers,
>> Guillaume Nodet
>> ------------------------
>> Blog: http://gnodet.blogspot.com/
>> ------------------------
>> Open Source SOA
>> http://fusesource.com
>>
>
>
>
> --
> Karl Pauls
> karlpauls@gmail.com
>



-- 
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com

Re: [all] OSGI - POOL-160

Posted by Karl Pauls <ka...@gmail.com>.
On Thu, Feb 25, 2010 at 5:11 PM, Guillaume Nodet <gn...@gmail.com> wrote:
> Guys, can we discuss that and come back with a statement we all agree on ?

Discuss what?

regards,

Karl

> ---------- Forwarded message ----------
> From: Niall Pemberton <ni...@gmail.com>
> Date: Thu, Feb 25, 2010 at 16:26
> Subject: Re: [all] OSGI - POOL-160
> To: Commons Developers List <de...@commons.apache.org>
>
>
> On Thu, Feb 25, 2010 at 3:17 PM, Jörg Schaible <jo...@gmx.de> wrote:
>> Hi Guillaime,
>>
>> Guillaume Nodet wrote at Donnerstag, 25. Februar 2010 15:49:
>>
>>> I just had a lively chat with Peter who kinda agreed that
>>> substitutability issue is mostly important for APIs.
>>>
>>> Please have a look at the Felix FAQ entry:
>>>   http://felix.apache.org/site/apache-felix-osgi-
>> faq.html#ApacheFelixOSGiFAQ-Shouldabundleimportitsownexportedpackages%253F
>>> I haven't written it, so I can't be blame for that one.
>>> The last paragraph says:
>>>     "The main time you want to export only, is if your bundle is
>>> purely a library bundle, then its packages will only be used if they
>>> are needed."
>>
>> what we are saying is, that none of us is an OSGi expert and before we
>> published the first artifact with such information, we took the advice of
>> the Apache Felix community. If they recommend now something different, we'd
>> like to get some "official" blessing for the changes, simply because we
>> cannot really review it.
>
> +1
>
> Niall
>
>
>>> In all cases, the current imports *are* wrong and need to be fixed,
>>> because the way they are written will fail if there is any
>>> incompatible change ever introduced (whatever the version).  And I
>>> don't think we should guarantee that, especially across major
>>> versions.
>>
>> What has been released is final. We're not able to change that anymore. All
>> we can do is to change the OSGi information for new releases.
>>
>>> Anyway, the problem is the following.
>>> You install commons-pool 1.5 in the osgi framework.
>>> Then you install commons-pool 1.4 later.
>>> What you end up with is:
>>>
>>> karaf@root> osgi:list -l | grep commons-pool
>>> [ 100] [Active     ] [            ] [       ] [   60]
>>> mvn:commons-pool/commons-pool/1.5.4
>>> [ 124] [Active     ] [            ] [       ] [   60]
>>> mvn:commons-pool/commons-pool/1.4
>>> karaf@root> packages:exports 100
>>> Commons Pool (100): org.apache.commons.pool.impl; version=1.5.4
>>> Commons Pool (100): org.apache.commons.pool; version=1.5.4
>>> karaf@root> packages:exports 124
>>> Apache Commons Pool Bundle (124): No active exported packages.
>>> karaf@root> packages:imports 124
>>> Commons Pool (100): org.apache.commons.pool.impl; version=1.5.4
>>> Commons Pool (100): org.apache.commons.pool; version=1.5.4
>>> karaf@root> osgi:start 170
>>> Error executing command: Unresolved constraint in bundle
>>> org.apache.activemq.activemq-pool [129]: package;
>>> (&(package=org.apache.commons.pool.impl)(version>=1.4.0)(!
>> (version>=1.5.0)))
>>
>> While I see an error, it does not tell me a lot ;-)
>>
>> - Jörg
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
>



-- 
Karl Pauls
karlpauls@gmail.com