On 9/20/11 6:08 PM, Alasdair Nottingham wrote:
Are you saying that OBR as it stands today cannot resolve the generic
requirement/capabilities from OSGi R4.3?
It can resolve them for the most part, but they have to be converted to
the OBR XML format, which I believe is the issue, since tools don't
support this yet.
-> richard
Thanks
Alasdair
On 20 September 2011 18:18, Guillaume Nodet<[email protected]> wrote:
Yeah, I agree that would be a good idea. We just need to have an
implementation to support those in obr first.
On Tue, Sep 20, 2011 at 19:07, Alasdair Nottingham<[email protected]> wrote:
+1
I'd do a +∞ but I don't think that is valid, and I don't know if you can
see
the infinity symbol.
Alasdair
On 20 September 2011 15: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]
--
Alasdair Nottingham
[email protected]
--
------------------------
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
