[all] OSGI - POOL-160

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

[all] OSGI - POOL-160

Phil Steitz
Can someone knowledgeable in OSGi header construction please have a
look at POOL-160.  IIUC, this applies to all recently released
commons components (unless [pool] is somehow individually borked).

Thanks!

Phil

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [all] OSGI - POOL-160

Guillaume Nodet
I'm not a committer on commons, but I've diagnosed the issue we had in
ServiceMix with the commons-pool bundles.
I can confirm that the patch is the right way to go.   If a bundle
acting as a library imports its own exported packages, you're bound to
a lot of problems.

This problem applies to all releases of commons-pool and maybe to
other commons-xxx components.
I need to try if, but a better way might be to change the
commons-parent pom with something like:

    <commons.osgi.export>org.apache.commons.*;version=${pom.version};-noimport</commons.osgi.export>

This should work the same (i.e. not import our own exports), but be
applicable to all modules.

On Thu, Feb 25, 2010 at 12:31, Phil Steitz <[hidden email]> wrote:

> Can someone knowledgeable in OSGi header construction please have a
> look at POOL-160.  IIUC, this applies to all recently released
> commons components (unless [pool] is somehow individually borked).
>
> Thanks!
>
> Phil
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>



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

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [all] OSGI - POOL-160

Jörg Schaible
Hi Guillaume,

Guillaume Nodet wrote at Donnerstag, 25. Februar 2010 14:13:

> I'm not a committer on commons, but I've diagnosed the issue we had in
> ServiceMix with the commons-pool bundles.
> I can confirm that the patch is the right way to go.   If a bundle
> acting as a library imports its own exported packages, you're bound to
> a lot of problems.

Well, this has come up before and was an explicit recommendation by the
experts:

Peter Kriens: "Bnd automatically imports all exports to allow
substitutability. If you do not do this, you create all kinds of standalone
class spaces and things will not work together. It is generally bad practice
to only export a package."

http://commons.markmail.org/message/lgmj7srrxhld42tp

> This problem applies to all releases of commons-pool and maybe to
> other commons-xxx components.
> I need to try if, but a better way might be to change the
> commons-parent pom with something like:
>
>     <commons.osgi.export>org.apache.commons.*;version=${pom.version};-
noimport</commons.osgi.export>
>
> This should work the same (i.e. not import our own exports), but be
> applicable to all modules.

I'd rather not chage this unless proven by the experts again...

- Jörg


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [all] OSGI - POOL-160

Phil Steitz
Jörg Schaible wrote:

> Hi Guillaume,
>
> Guillaume Nodet wrote at Donnerstag, 25. Februar 2010 14:13:
>
>> I'm not a committer on commons, but I've diagnosed the issue we had in
>> ServiceMix with the commons-pool bundles.
>> I can confirm that the patch is the right way to go.   If a bundle
>> acting as a library imports its own exported packages, you're bound to
>> a lot of problems.
>
> Well, this has come up before and was an explicit recommendation by the
> experts:
>
> Peter Kriens: "Bnd automatically imports all exports to allow
> substitutability. If you do not do this, you create all kinds of standalone
> class spaces and things will not work together. It is generally bad practice
> to only export a package."
>
> http://commons.markmail.org/message/lgmj7srrxhld42tp
>
>> This problem applies to all releases of commons-pool and maybe to
>> other commons-xxx components.
>> I need to try if, but a better way might be to change the
>> commons-parent pom with something like:
>>
>>     <commons.osgi.export>org.apache.commons.*;version=${pom.version};-
> noimport</commons.osgi.export>
>> This should work the same (i.e. not import our own exports), but be
>> applicable to all modules.
>
> I'd rather not chage this unless proven by the experts again...
>
> - Jörg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
Thx, Jorg.  Can you add this to the ticket, pls.  Thanks.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [all] OSGI - POOL-160

Jörg Schaible
Phil Steitz wrote at Donnerstag, 25. Februar 2010 14:39:

[snip]

> Thx, Jorg.  Can you add this to the ticket, pls.  Thanks.

Niall has beaten me :)

- Jörg



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [all] OSGI - POOL-160

Jörg Schaible
Jörg Schaible wrote at Donnerstag, 25. Februar 2010 14:44:

> Phil Steitz wrote at Donnerstag, 25. Februar 2010 14:39:
>
> [snip]
>
>> Thx, Jorg.  Can you add this to the ticket, pls.  Thanks.
>
> Niall has beaten me :)

Maybe we should add this comment also to the wiki for our own remembrance
and as documentation for others. Since Niall maintains that page normally
and I am not a native speaker, I let him find the proper place for the cite.
;-)

- Jörg


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [all] OSGI - POOL-160

Guillaume Nodet
In reply to this post by Jörg Schaible
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."

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.

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)))


On Thu, Feb 25, 2010 at 14:26, Jörg Schaible <[hidden email]> wrote:

> Hi Guillaume,
>
> Guillaume Nodet wrote at Donnerstag, 25. Februar 2010 14:13:
>
>> I'm not a committer on commons, but I've diagnosed the issue we had in
>> ServiceMix with the commons-pool bundles.
>> I can confirm that the patch is the right way to go.   If a bundle
>> acting as a library imports its own exported packages, you're bound to
>> a lot of problems.
>
> Well, this has come up before and was an explicit recommendation by the
> experts:
>
> Peter Kriens: "Bnd automatically imports all exports to allow
> substitutability. If you do not do this, you create all kinds of standalone
> class spaces and things will not work together. It is generally bad practice
> to only export a package."
>
> http://commons.markmail.org/message/lgmj7srrxhld42tp
>
>> This problem applies to all releases of commons-pool and maybe to
>> other commons-xxx components.
>> I need to try if, but a better way might be to change the
>> commons-parent pom with something like:
>>
>>     <commons.osgi.export>org.apache.commons.*;version=${pom.version};-
> noimport</commons.osgi.export>
>>
>> This should work the same (i.e. not import our own exports), but be
>> applicable to all modules.
>
> I'd rather not chage this unless proven by the experts again...
>
> - Jörg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>



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

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [all] OSGI - POOL-160

Jörg Schaible
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.

> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [all] OSGI - POOL-160

Niall Pemberton
On Thu, Feb 25, 2010 at 3:17 PM, Jörg Schaible <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Fwd: [all] OSGI - POOL-160

Guillaume Nodet
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 <[hidden email]>
Date: Thu, Feb 25, 2010 at 18:01
Subject: Re: [all] OSGI - POOL-160
To: [hidden email]


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 <[hidden email]> 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<[hidden email]>  wrote:
>>
>>>
>>> On Thu, Feb 25, 2010 at 5:17 PM, Guillaume Nodet<[hidden email]>
>>>  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<[hidden email]>  wrote:
>>>>
>>>>>
>>>>> On Thu, Feb 25, 2010 at 5:11 PM, Guillaume Nodet<[hidden email]>
>>>>>  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<[hidden email]>
>>>>>> Date: Thu, Feb 25, 2010 at 16:26
>>>>>> Subject: Re: [all] OSGI - POOL-160
>>>>>> To: Commons Developers List<[hidden email]>
>>>>>>
>>>>>>
>>>>>> On Thu, Feb 25, 2010 at 3:17 PM, Jörg Schaible<[hidden email]>
>>>>>>  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: [hidden email]
>>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: [hidden email]
>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Cheers,
>>>>>> Guillaume Nodet
>>>>>> ------------------------
>>>>>> Blog: http://gnodet.blogspot.com/
>>>>>> ------------------------
>>>>>> Open Source SOA
>>>>>> http://fusesource.com
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Karl Pauls
>>>>> [hidden email]
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Cheers,
>>>> Guillaume Nodet
>>>> ------------------------
>>>> Blog: http://gnodet.blogspot.com/
>>>> ------------------------
>>>> Open Source SOA
>>>> http://fusesource.com
>>>>
>>>>
>>>
>>>
>>> --
>>> Karl Pauls
>>> [hidden email]
>>>
>>>
>>
>>
>>
>



--
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [all] OSGI - POOL-160

Niall Pemberton
On Thu, Feb 25, 2010 at 5:02 PM, Guillaume Nodet <[hidden email]> 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 <[hidden email]>
> Date: Thu, Feb 25, 2010 at 18:01
> Subject: Re: [all] OSGI - POOL-160
> To: [hidden email]
>
>
> 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 <[hidden email]> 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<[hidden email]>  wrote:
>>>
>>>>
>>>> On Thu, Feb 25, 2010 at 5:17 PM, Guillaume Nodet<[hidden email]>
>>>>  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<[hidden email]>  wrote:
>>>>>
>>>>>>
>>>>>> On Thu, Feb 25, 2010 at 5:11 PM, Guillaume Nodet<[hidden email]>
>>>>>>  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<[hidden email]>
>>>>>>> Date: Thu, Feb 25, 2010 at 16:26
>>>>>>> Subject: Re: [all] OSGI - POOL-160
>>>>>>> To: Commons Developers List<[hidden email]>
>>>>>>>
>>>>>>>
>>>>>>> On Thu, Feb 25, 2010 at 3:17 PM, Jörg Schaible<[hidden email]>
>>>>>>>  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: [hidden email]
>>>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: [hidden email]
>>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Cheers,
>>>>>>> Guillaume Nodet
>>>>>>> ------------------------
>>>>>>> Blog: http://gnodet.blogspot.com/
>>>>>>> ------------------------
>>>>>>> Open Source SOA
>>>>>>> http://fusesource.com
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Karl Pauls
>>>>>> [hidden email]
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Cheers,
>>>>> Guillaume Nodet
>>>>> ------------------------
>>>>> Blog: http://gnodet.blogspot.com/
>>>>> ------------------------
>>>>> Open Source SOA
>>>>> http://fusesource.com
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Karl Pauls
>>>> [hidden email]
>>>>
>>>>
>>>
>>>
>>>
>>
>
>
>
> --
> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [all] OSGI - POOL-160

Phil Steitz
Niall Pemberton wrote:

> On Thu, Feb 25, 2010 at 5:02 PM, Guillaume Nodet <[hidden email]> 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 <[hidden email]>
>> Date: Thu, Feb 25, 2010 at 18:01
>> Subject: Re: [all] OSGI - POOL-160
>> To: [hidden email]
>>
>>
>> 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 <[hidden email]> 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<[hidden email]>  wrote:
>>>>
>>>>> On Thu, Feb 25, 2010 at 5:17 PM, Guillaume Nodet<[hidden email]>
>>>>>  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<[hidden email]>  wrote:
>>>>>>
>>>>>>> On Thu, Feb 25, 2010 at 5:11 PM, Guillaume Nodet<[hidden email]>
>>>>>>>  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<[hidden email]>
>>>>>>>> Date: Thu, Feb 25, 2010 at 16:26
>>>>>>>> Subject: Re: [all] OSGI - POOL-160
>>>>>>>> To: Commons Developers List<[hidden email]>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Thu, Feb 25, 2010 at 3:17 PM, Jörg Schaible<[hidden email]>
>>>>>>>>  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: [hidden email]
>>>>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: [hidden email]
>>>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Cheers,
>>>>>>>> Guillaume Nodet
>>>>>>>> ------------------------
>>>>>>>> Blog: http://gnodet.blogspot.com/
>>>>>>>> ------------------------
>>>>>>>> Open Source SOA
>>>>>>>> http://fusesource.com
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Karl Pauls
>>>>>>> [hidden email]
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> Cheers,
>>>>>> Guillaume Nodet
>>>>>> ------------------------
>>>>>> Blog: http://gnodet.blogspot.com/
>>>>>> ------------------------
>>>>>> Open Source SOA
>>>>>> http://fusesource.com
>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> Karl Pauls
>>>>> [hidden email]
>>>>>
>>>>>
>>>>
>>>>
>>
>>
>> --
>> 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: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [all] OSGI - POOL-160

Guillaume Nodet
In reply to this post by Niall Pemberton
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
<[hidden email]> wrote:

> On Thu, Feb 25, 2010 at 5:02 PM, Guillaume Nodet <[hidden email]> 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 <[hidden email]>
>> Date: Thu, Feb 25, 2010 at 18:01
>> Subject: Re: [all] OSGI - POOL-160
>> To: [hidden email]
>>
>>
>> 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 <[hidden email]> 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<[hidden email]>  wrote:
>>>>
>>>>>
>>>>> On Thu, Feb 25, 2010 at 5:17 PM, Guillaume Nodet<[hidden email]>
>>>>>  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<[hidden email]>  wrote:
>>>>>>
>>>>>>>
>>>>>>> On Thu, Feb 25, 2010 at 5:11 PM, Guillaume Nodet<[hidden email]>
>>>>>>>  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<[hidden email]>
>>>>>>>> Date: Thu, Feb 25, 2010 at 16:26
>>>>>>>> Subject: Re: [all] OSGI - POOL-160
>>>>>>>> To: Commons Developers List<[hidden email]>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Thu, Feb 25, 2010 at 3:17 PM, Jörg Schaible<[hidden email]>
>>>>>>>>  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: [hidden email]
>>>>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: [hidden email]
>>>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Cheers,
>>>>>>>> Guillaume Nodet
>>>>>>>> ------------------------
>>>>>>>> Blog: http://gnodet.blogspot.com/
>>>>>>>> ------------------------
>>>>>>>> Open Source SOA
>>>>>>>> http://fusesource.com
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Karl Pauls
>>>>>>> [hidden email]
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Cheers,
>>>>>> Guillaume Nodet
>>>>>> ------------------------
>>>>>> Blog: http://gnodet.blogspot.com/
>>>>>> ------------------------
>>>>>> Open Source SOA
>>>>>> http://fusesource.com
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Karl Pauls
>>>>> [hidden email]
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>
>>
>>
>> --
>> 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: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>



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

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [all] OSGI - POOL-160

Niall Pemberton
On Fri, Feb 26, 2010 at 2:45 PM, Guillaume Nodet <[hidden email]> 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
> <[hidden email]> wrote:
>> On Thu, Feb 25, 2010 at 5:02 PM, Guillaume Nodet <[hidden email]> 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 <[hidden email]>
>>> Date: Thu, Feb 25, 2010 at 18:01
>>> Subject: Re: [all] OSGI - POOL-160
>>> To: [hidden email]
>>>
>>>
>>> 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 <[hidden email]> 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<[hidden email]>  wrote:
>>>>>
>>>>>>
>>>>>> On Thu, Feb 25, 2010 at 5:17 PM, Guillaume Nodet<[hidden email]>
>>>>>>  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<[hidden email]>  wrote:
>>>>>>>
>>>>>>>>
>>>>>>>> On Thu, Feb 25, 2010 at 5:11 PM, Guillaume Nodet<[hidden email]>
>>>>>>>>  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<[hidden email]>
>>>>>>>>> Date: Thu, Feb 25, 2010 at 16:26
>>>>>>>>> Subject: Re: [all] OSGI - POOL-160
>>>>>>>>> To: Commons Developers List<[hidden email]>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Thu, Feb 25, 2010 at 3:17 PM, Jörg Schaible<[hidden email]>
>>>>>>>>>  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: [hidden email]
>>>>>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: [hidden email]
>>>>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Cheers,
>>>>>>>>> Guillaume Nodet
>>>>>>>>> ------------------------
>>>>>>>>> Blog: http://gnodet.blogspot.com/
>>>>>>>>> ------------------------
>>>>>>>>> Open Source SOA
>>>>>>>>> http://fusesource.com
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Karl Pauls
>>>>>>>> [hidden email]
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Cheers,
>>>>>>> Guillaume Nodet
>>>>>>> ------------------------
>>>>>>> Blog: http://gnodet.blogspot.com/
>>>>>>> ------------------------
>>>>>>> Open Source SOA
>>>>>>> http://fusesource.com
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Karl Pauls
>>>>>> [hidden email]
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> 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: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]