commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niall Pemberton <niall.pember...@gmail.com>
Subject Re: [all] OSGI - POOL-160
Date Fri, 26 Feb 2010 17:47:23 GMT
On Fri, Feb 26, 2010 at 2:45 PM, Guillaume Nodet <gnodet@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
> <niall.pemberton@gmail.com> wrote:
>> On Thu, Feb 25, 2010 at 5:02 PM, Guillaume Nodet <gnodet@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 <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
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> 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


Mime
View raw message