commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guillaume Nodet <gno...@gmail.com>
Subject Fwd: [all] OSGI - POOL-160
Date Thu, 25 Feb 2010 17:02:34 GMT
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 <gnodet@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 <heavy@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<karlpauls@gmail.com>  wrote:
>>
>>>
>>> On Thu, Feb 25, 2010 at 5:17 PM, Guillaume Nodet<gnodet@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<karlpauls@gmail.com>  wrote:
>>>>
>>>>>
>>>>> On Thu, Feb 25, 2010 at 5:11 PM, Guillaume Nodet<gnodet@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<niall.pemberton@gmail.com>
>>>>>> Date: Thu, Feb 25, 2010 at 16:26
>>>>>> Subject: Re: [all] OSGI - POOL-160
>>>>>> To: Commons Developers List<dev@commons.apache.org>
>>>>>>
>>>>>>
>>>>>> On Thu, Feb 25, 2010 at 3:17 PM, Jörg Schaible<joerg.schaible@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


Mime
View raw message