Mailing-List: contact dev-help@felix.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@felix.apache.org
Received-SPF: pass (nike.apache.org: domain of karlpauls@gmail.com designates
 209.85.160.49 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type:content-transfer-encoding;
        b=HOQNmsKihRZ9PRgjByZGQhNfvMxJlOxSa5F9HbJOu5N62/eYxvSmpPQamYv0yKLIKb
         So1cjPrijgMOxdKj6xSteoCmTZkTV1BjvCACMuVdI9TDcLNFAqFMy69T71Hdb8/sBNWg
         29FbQrc1zR86K5gEWOvpOIIVozI24gI0yaMgU=
MIME-Version: 1.0
In-Reply-To: <b23ecedc1002250817s6302d63bu2d51ba3a8874d36a@mail.gmail.com>
References: <4B865F90.40108@gmail.com>
	 <b23ecedc1002250513o78dbc7f5w1b0c8d3406eab650@mail.gmail.com>
	 <hm5tqs$26k$1@dough.gmane.org>
	 <b23ecedc1002250649v6810012cqce799b184af578b6@mail.gmail.com>
	 <hm64am$r0q$1@dough.gmane.org>
	 <55afdc851002250726n23df74d2r7d60e3a490e626ec@mail.gmail.com>
	 <b23ecedc1002250811v380089dev2cd046cfd97e3705@mail.gmail.com>
	 <487a994c1002250815g57423918k73e3ab75dc15483a@mail.gmail.com>
	 <b23ecedc1002250817s6302d63bu2d51ba3a8874d36a@mail.gmail.com>
Date: Thu, 25 Feb 2010 17:23:50 +0100
Message-ID: <487a994c1002250823j3fd5b4f6yc13bc288492ff28b@mail.gmail.com>
Subject: Re: [all] OSGI - POOL-160
From: Karl Pauls <karlpauls@gmail.com>
To: dev@felix.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

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> wrot=
e:
>>> Guys, can we discuss that and come back with a statement we all agree o=
n ?
>>
>> 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=F6rg 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:
>>>>> =A0 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:
>>>>> =A0 =A0 "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 w=
e
>>>> 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). =A0And 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 =A0 =A0 ] [ =A0 =A0 =A0 =A0 =A0 =A0] [ =A0 =A0 =A0 ] [=
 =A0 60]
>>>>> mvn:commons-pool/commons-pool/1.5.4
>>>>> [ 124] [Active =A0 =A0 ] [ =A0 =A0 =A0 =A0 =A0 =A0] [ =A0 =A0 =A0 ] [=
 =A0 60]
>>>>> mvn:commons-pool/commons-pool/1.4
>>>>> karaf@root> packages:exports 100
>>>>> Commons Pool (100): org.apache.commons.pool.impl; version=3D1.5.4
>>>>> Commons Pool (100): org.apache.commons.pool; version=3D1.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=3D1.5.4
>>>>> Commons Pool (100): org.apache.commons.pool; version=3D1.5.4
>>>>> karaf@root> osgi:start 170
>>>>> Error executing command: Unresolved constraint in bundle
>>>>> org.apache.activemq.activemq-pool [129]: package;
>>>>> (&(package=3Dorg.apache.commons.pool.impl)(version>=3D1.4.0)(!
>>>> (version>=3D1.5.0)))
>>>>
>>>> While I see an error, it does not tell me a lot ;-)
>>>>
>>>> - J=F6rg
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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
>


--=20
Karl Pauls
karlpauls@gmail.com