Re: Remove Import-Service header in MANIFEST (was Re: svn commit: r1151765 - in /felix/trunk/eventadmin/impl: changelog.txt pom.xml)

Tue, 20 Sep 2011 08:28:55 -0700 

On 9/20/11 10:08 AM, Guillaume Nodet wrote:

Yeah, but the implementation do not yet leverage those headers, but I agree
we can start the discussion about defining some namespaces we want to use
for certain applications like services and extenders.



One thing to point out, how we've been modeling service dependencies in 
OBR is not correct.



Typically, they are expressed as a package dependency on the service API 
and a service dependency on a service provider. The issue with this 
approach is that these two dependencies can be resolved independently of 
each other. For example, the package dependency can be wired to a 
different API version than the provider of the service, since there is 
no constraint between the two.



This issued is resolved with the new Provide-Capability header, since 
the service provider can now declare that it has a "uses" constraint on 
its imported (or exported) service API package. Thus, a 
Require-Capability for the service provider will constrain the requirer 
to the same service API package as the service provider.


-> richard



On Tue, Sep 20, 2011 at 16:01, Richard S. Hall<[email protected]>  wrote:


On 9/20/11 9:47 AM, Guillaume Nodet wrote:


The osgi core spec specifies how the osgi framework behaves.   This header
is not used anymore by the osgi framework, and only mentioned as being for
informational purposes, which is how we use it here (from the osgi core
point of view).

That said, I'll add this header back as its presence doesn't really cause
any trouble, while its removal actually broke my applications (because
it's
used by the maven bundle plugin and felix obr implementation).

I don't have any problem changing the whole solution, but I'd much rather
do
that when the new obr spec will be published and the felix implementation
done, so that we can have a nice way to express those constraints.   I
don't
really want to change the whole thing twice in a year.   This would also
be
a good time to discuss a way to indicate how extenders information can be
put into those obr constraints and leveraged nicely.


You actually don't need to wait for the OBR spec to be able to express
these dependencies. In fact, the OBR spec doesn't say how to express them.
However, the R4.3 core spec released earlier this year introduced
Provide-Capability/Require-**Capability headers that can be used right
now. So, you might as well start using them.

->  richard




On Tue, Sep 20, 2011 at 15:01, Alasdair Nottingham<[email protected]>
  wrote:

  No it doesn't, however that is irrelevant in my mind. Standards exist for

a
reason. This header is owned and specified by the OSGi alliance. If you
want
to use a more expressive syntax you can invent your own header. If people
ignore standards because "it doesn't work for them" then what value do
standards provide.

Alasdair

On 20 September 2011 12:23, Guillaume Nodet<[email protected]>   wrote:

  Well, does it actually cause any problem to you ?  I've asked more than

once
but had no answer.
Because removing those headers actually cause problems to me.

Fwiw, the discussions we had in the felix community lead that those


headers


were acceptable.
Maybe we can revisit and find a better way with the new OBR spec
provided
that those constraints can be captured.

On Tue, Sep 20, 2011 at 11:14, Alasdair Nottingham<[email protected]>


wrote:


  Hi,

As I have said many times in the past it is not valid to put attributes
into
an Import-Service header. The OSGi Alliance specification that defines


the


syntax says it is a comma separated list of service interface/class


names.


I
support any effort that reduces the use of invalid OSGi header syntax.

Alasdair

On 20 September 2011 08:12, Guillaume Nodet<[email protected]>   wrote:

  Unless I hear something, I plan to revert this change.

On Thu, Sep 8, 2011 at 15:42, Guillaume Nodet<[email protected]>


wrote:

  What is the reason for removing those informations ?

Those are used when computing the obr constraints ... and actually
used when resolving using OBR.

On Thu, Jul 28, 2011 at 10:48,<[email protected]>   wrote:


Author: cziegeler
Date: Thu Jul 28 08:48:27 2011
New Revision: 1151765

URL: 
http://svn.apache.org/viewvc?**rev=1151765&view=rev<http://svn.apache.org/viewvc?rev=1151765&view=rev>
Log:
FELIX-2156 - Remove Import-Service header in MANIFEST

Modified:
    felix/trunk/eventadmin/impl/**changelog.txt
    felix/trunk/eventadmin/impl/**pom.xml

Modified: felix/trunk/eventadmin/impl/**changelog.txt
URL:




  http://svn.apache.org/viewvc/**felix/trunk/eventadmin/impl/**

changelog.txt?rev=1151765&r1=**1151764&r2=1151765&view=diff<http://svn.apache.org/viewvc/felix/trunk/eventadmin/impl/changelog.txt?rev=1151765&r1=1151764&r2=1151765&view=diff>


  ==============================**==============================**

==================


--- felix/trunk/eventadmin/impl/**changelog.txt (original)

+++ felix/trunk/eventadmin/impl/**changelog.txt Thu Jul 28 08:48:27


2011

@@ -7,6 +7,9 @@ Changes from 1.2.12 to 1.2.14

     * [FELIX-3053] - Potential deadlock if event handler throws


Throwable
and is bypassing timeout handling


     * [FELIX-3055] - Event Admin deadlocks when sendEvent is


called

from

within a handleEvent method


+** Improvement
+    * [FELIX-2156] - Remove Import-Service header in MANIFEST
+

  Changes from 1.2.10 to 1.2.12
  -----------------------------

Modified: felix/trunk/eventadmin/impl/**pom.xml
URL:




  http://svn.apache.org/viewvc/**felix/trunk/eventadmin/impl/**

pom.xml?rev=1151765&r1=**1151764&r2=1151765&view=diff<http://svn.apache.org/viewvc/felix/trunk/eventadmin/impl/pom.xml?rev=1151765&r1=1151764&r2=1151765&view=diff>


  ==============================**==============================**

==================


--- felix/trunk/eventadmin/impl/**pom.xml (original)

+++ felix/trunk/eventadmin/impl/**pom.xml Thu Jul 28 08:48:27 2011
@@ -98,14 +98,6 @@
                         </Import-Package>

  <Export-Package>org.osgi.**service.event</Export-Package>


  <Private-Package>org.apache.**felix.eventadmin.impl.*</**

Private-Package>


-<Import-Service>

-




   org.osgi.service.event.**EventHandler;availability:=**

optional;multiple:=true,


-



   org.osgi.service.log.**LogService;availability:=**

optional;multiple:=false,


-



   org.osgi.service.log.**LogReaderService;availability:**

=optional;multiple:=false


-</Import-Service>

-<Export-Service>
-                           org.osgi.service.event.**EventAdmin
-</Export-Service>
                         <!-- Include concurrent lib but not sub


packages
-->


                         <Embed-Dependency>

  concurrent;inline="EDU/oswego/**cs/dl/util/concurrent/[A-Z]*"





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




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




--
Alasdair Nottingham
[email protected]




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




--
Alasdair Nottingham
[email protected]





























					Reply via email to