Re: [equinox-dev] How much of the R4.2 spec is implemented in Equinox

[Jens Lauterbach]

Thank you all for your quick reply!

I am going to update my chart and come back to you if I have more questions.

Best regards
Jens

On 06.04.2010, at 00:06, Scott Lewis wrote:

> Sorry...here are the refs:
> 
> [1] http://eclipseecf.blogspot.com/2010/02/ecf-32-now-available.html
> [2] http://eclipseecf.blogspot.com/2010/01/osgi-remote-services-from-ecf.html
> 
> 
> Scott Lewis wrote:
>> Hi Jens,
>> 
>> Jens Lauterbach wrote:
>>> 
>>> So I'm curious about the other specs not listed on this page:
>>> 
>>> 
>>>• UPnP Device Service
>>>• Remote Services
>>>  
>> 
>> The Eclipse Communication Framework (3.2) project (part of EclipseRT, but 
>> not Equinox project specifically) fully implements the Remote Services 
>> specification from OSGi 4.2 spec (chap 13).  ECF 3.2 was released in Feb 
>> [1], and here's a description of some of the technical characteristics of 
>> the OSGi 4.2 impl along with links to docs and examples [2].
>> 
>> Scott
>> 
>> ___
>> equinox-dev mailing list
>> equinox-dev@eclipse.org
>> https://dev.eclipse.org/mailman/listinfo/equinox-dev
> 
> ___
> equinox-dev mailing list
> equinox-dev@eclipse.org
> https://dev.eclipse.org/mailman/listinfo/equinox-dev

___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

RE: [equinox-dev] Re: [p2-dev] who should declare dependencies on ds?

[Murphree, Michael]

For what it's worth, the Apache developers dodged this problem by not
decoupling the packaging of the service interface with implementation of
the service.  Instead, they relied on declaring imports for the service
interface as well as exporting it.  Rather than use the interfaces on
the internal classpath of the bundle, the OSGi framework would have the
opportunity to wire in those same interfaces as exported from some other
bundle.

 

The drawback to this is that if we never decouple the packaging of a
service interface from its implementation, we can never exclusively
replace an implementation of the service if we do not have its source
(we must replace the service interface also).  I don't know if this is a
good solution to this particular problem (package the egg and flour
premixed, to extend the metaphor), but it will work in some cases.

 

Regards,

 

Michael

 

From: equinox-dev-boun...@eclipse.org
[mailto:equinox-dev-boun...@eclipse.org] On Behalf Of Jeff McAffer
Sent: Friday, April 02, 2010 4:58 PM
To: P2 developer discussions
Cc: Equinox development mailing list
Subject: Re: [equinox-dev] Re: [p2-dev] who should declare dependencies
on ds?

 

Good point Jason.  I would generalize it even more and say that it is
not just DI but the decoupling that comes with services (or the
extension registry for that matter).  We decouple bundles to they don't
depend on specific implementations but then do not have a mechanism for
spec'ing that they actually need an implementation. There is the
component definition in DS etc but p2 or someone else has to
read/understand that.  The unique thing about DS is that it is even more
removed.

 

You could say , "hey, the bundle has DS markup so it must need DS" While
that is likely true in many cases, it is also possible that the same
bundle could be used with and without DS.  It may contain other markup
for other DI mechanisms.  These have to be dealt with at a higher level
as you say.

 

Jeff

 

On 2010-04-02, at 4:40 PM, Jason Barkanic wrote:





In general this is a problem with any kind of dependency injection,
although in this case nothing is actually being injected, but it is
being set up and managed by an outside component.  

 

Do you set up a dependency on the dependency injector?  How do you best
notify clients that they need the dependency injection framework with
your config, or else they'll have to set things up themselves?  It's not
even different implementations of DS, but you could substitute in
Blueprint, or Spring, without changing the API (that is if you don't
define API to include one particular set of bundles over another).

 

This kind of thing is annoying though (I've been a victim).  I'm
interested to see what solutions present themselves as more and more
people move to DI and Services paradigms.  I think good error messages
can help, since that might have alleviated your 6 week search in the
first place, but that is easier said than done.  The error message could
make suggestions about why a service lookup failed, but it's hard
[impossible] to really know.

 -Jason

 

 

Phil Wrote:

=

 

I can appreciate the desire to allow different DS implementations but
the bottom line is that DS is going to break any RCP application that
uses P2 (there may be other fall out as well).  My RCP app uses P2 so I
thought that I should download 3.6M5 so that I had time to make comments
about the API before the API freeze.  When I updated not only did my
auto update functionality break, but my build server broke also (PDE
build with P2).  It took 6 weeks of googling before I figured out that
there was this new DS bundle that I not only had to include, but I also
had to be responsible for starting.

 

All is well for me now, but I fear that this change is going to have a
big impact when 3.6 releases.  At a minimum this needs to be documented
probably both in "What's New" in the "Plug-In Development Environment
Guide" and also in the 3.6 Plug-in Migration Guide.  Getting the
rcpupdate example updated (bug 307558) was a good step in the right
direction.

 

Thanks,

Phil

 

On Thu, Apr 1, 2010 at 1:50 PM, Thomas Watson 
wrote:

Note that Equinox does have the ability to declare non-code dependencies
in bundle manifests. See Eclipse-GenericCapability and
Eclipse-GenericRequire headers at:

http://help.eclipse.org/galileo/index.jsp?topic=/org.eclipse.platform.do
c.isv/reference/misc/bundle_manifest.html

This could be used by the DS implementation to declare a DS runtime
capability and bundles defining DS components could declare a
requirement on the DS runtime capability. But this mechanism only
describes resolve time dependencies. It still would not solve Jeff's
other concerns about the need to have DS active in order to truly work.
Also note that p2 meta-data currently does not reflect the generic
capabilities/requirements declared in a bundle

Re: [equinox-dev] How much of the R4.2 spec is implemented in Equinox

[Scott Lewis]

Sorry...here are the refs:

[1] http://eclipseecf.blogspot.com/2010/02/ecf-32-now-available.html
[2] 
http://eclipseecf.blogspot.com/2010/01/osgi-remote-services-from-ecf.html



Scott Lewis wrote:

Hi Jens,

Jens Lauterbach wrote:


So I'm curious about the other specs not listed on this page:


• UPnP Device Service
• Remote Services
  


The Eclipse Communication Framework (3.2) project (part of EclipseRT, 
but not Equinox project specifically) fully implements the Remote 
Services specification from OSGi 4.2 spec (chap 13).  ECF 3.2 was 
released in Feb [1], and here's a description of some of the technical 
characteristics of the OSGi 4.2 impl along with links to docs and 
examples [2].


Scott

___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev


___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

[equinox-dev] Equinox contribution to the Helios Integration build.

[Thomas Watson]

The map file has been updated for the following Bug changes:
+ Bug 111719. importing existing plugins locks jars (FIXED)
+ Bug 267683. Enhancements to the tracing framework (FIXED)
+ Bug 300820. Failure in testBug289719 on I20100125-0800 build (FIXED)
+ Bug 307209. ZipException missing filename (FIXED)
+ Bug 307575. Equinox features in Helios with incorrect license (FIXED)

The following projects have changed:
org.eclipse.equinox.server.core
org.eclipse.equinox.server.p2
org.eclipse.equinox.server.servletbridge
org.eclipse.equinox.supplement
org.eclipse.equinox.server.simple
org.eclipse.osgi.tests
org.eclipse.equinox.server.jetty
org.eclipse.osgi

Tom
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] How much of the R4.2 spec is implemented in Equinox

[Thomas Watson]

I'm having issues posting to the forum (where I would prefer to answer
this).

The first two lists look correct.  Taking a look at the third list:

[*] UPnP Device Service - Not implemented

[*] Remote Services - Not in Equinox. Implemented in ECF at Eclipse RT

[*] Deployment Admin - Not implemented

[*] Auto Configuration - Not implemented

[*] Application Admin - Implemented in the Equinox application container
(org.eclipse.equinox.app)

[*] DMT Admin Service - Not implemented

[*] Monitor Admin Service - Not implemented

[*] Foreign Application Access - Not implemented

[*] Blueprint Container - Not in Equinox.  Implemented in Gemini at Eclipse
RT

[*] Tracker - implemented as part of the org.osgi.util.tracker package.
Included in org.eclipse.osgi

[*] XML Parser Service - implemented on VMs that include JAXP (J2SE 1.4 or
higher).  Included in the org.eclipse.osgi.  For embedded VM I know eRCP
project at Eclipse RT has implementations available.

[*] Position - implemented as part of the org.osgi.util.position package.
Included in the org.eclipse.osgi.util bundle.

[*] Measurement and State - implemented as part of the
org.osgi.util.measurement package.  Included in the org.eclipse.osgi.util
bundle

[*] Execution Environment - No one really implemented really implements
this.  The VM provides the execution environment and the framework is
responsible for the following.  Validating
Bundle-RequiredExecutionEnvironment.  Setting various org.osgi.framework
properties to reflect the execution environment.  Export the non-java.*
packages included in the running execution environment from the system
bundle.  This is implemented by org.eclipse.osgi.



Tom




|>
| From:  |
|>
  
>--|
  |Jens Lauterbach  
 |
  
>--|
|>
| To:|
|>
  
>--|
  |equinox-dev@eclipse.org  
 |
  
>--|
|>
| Date:  |
|>
  
>--|
  |04/05/2010 04:00 PM  
 |
  
>--|
|>
| Subject:   |
|>
  
>--|
  |[equinox-dev] How much of the R4.2 spec is implemented in Equinox
 |
  
>--|





Hello,

I hope hope I am at the right place. I've asked the following question(s)
in the forums  and on irc but never got a answer so I am trying it here.

Right now I am working on a paper in which I am comparing Equinox, Felix
and Knopflerfish in terms of OSGi 4.2 compliance.

Therefor I looked around on the Equinox page and found some clues:

If I am correct it seems like all of the core specs are fully implemented.
Is that correct?

Core:

 • Security Layer
 • Module Layer
 • Life Cycle Layer
 • Service Layer
 • Framework API
 • Package Admin Service
 • Start Level Servcie
 • Conditional Permission Admin Service
 • URL Handlers Service
 • Service Hooks

According to the "bundles" page the following Compendium specs are fully
implemented:

 • Log Service
 • Http Service
 • Device Access
 • Configuration Admin Service
 • Metatype Service
 • Preferences Service
 • User Admin Service
 • Wire Admin Service
 • IO Connector Service
 • Initial Provisioning
 • Declarative Services
  

Re: [equinox-dev] How much of the R4.2 spec is implemented in Equinox

[Scott Lewis]

Hi Jens,

Jens Lauterbach wrote:


So I'm curious about the other specs not listed on this page:


• UPnP Device Service
• Remote Services
  


The Eclipse Communication Framework (3.2) project (part of EclipseRT, 
but not Equinox project specifically) fully implements the Remote 
Services specification from OSGi 4.2 spec (chap 13).  ECF 3.2 was 
released in Feb [1], and here's a description of some of the technical 
characteristics of the OSGi 4.2 impl along with links to docs and 
examples [2].


Scott

___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

[equinox-dev] How much of the R4.2 spec is implemented in Equinox

[Jens Lauterbach]

Hello,

I hope hope I am at the right place. I've asked the following question(s) in 
the forums  and on irc but never got a answer so I am trying it here.

Right now I am working on a paper in which I am comparing Equinox, Felix and 
Knopflerfish in terms of OSGi 4.2 compliance.

Therefor I looked around on the Equinox page and found some clues:

If I am correct it seems like all of the core specs are fully implemented. Is 
that correct?

Core:

• Security Layer
• Module Layer
• Life Cycle Layer
• Service Layer
• Framework API
• Package Admin Service
• Start Level Servcie
• Conditional Permission Admin Service
• URL Handlers Service
• Service Hooks

According to the "bundles" page the following Compendium specs are fully 
implemented:

• Log Service
• Http Service
• Device Access
• Configuration Admin Service
• Metatype Service
• Preferences Service
• User Admin Service
• Wire Admin Service
• IO Connector Service
• Initial Provisioning
• Declarative Services
• Event Admin Service


So I'm curious about the other specs not listed on this page:


• UPnP Device Service
• Remote Services
• Deployment Admin
• Auto Configuration
• Application Admin
• DMT Admin Service
• Monitor Admin Service
• Foreign Application Access
• Blueprint Container
• Tracker
• XML Parser Service
• Position
• Measurement and State
• Execution Environment


Which of them are implemented right now (4.2 spec)?

You can also find this question in the forums:

http://www.eclipse.org/forums/index.php?t=msg&goto=524932&#msg_524932

Best regards
Jens

___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] Re: [GSoC] Restlet integration with Equinox

[Scott Lewis]

Hi Rob,

Rob Heittman wrote:

Inline:

On Sun, Apr 4, 2010 at 6:01 PM, Scott Lewis > wrote:


My only comment about discovery is that ECF also has a discovery
API (org.eclipse.ecf.discovery) ...

 
[snip]
 


The OSGi remote services spec defines a thing called a 'config
type'...which is just a String that uniquely identifies a type of
remote service provider.  ECF maps this 'config type' to identify
an ECF IContainer type/factory...and this string identified the
provider used underneath (e.g. ecf.r-osgi.peer,
ecf.generic.client, ecf.xmpp.client, etc)...so to use a particular
provider/protocol to register/publish a remote service all one has
to do is create a provider with new name, specify it as the config
type to use when registering a remote service, and that provider
will be used.


Good.  I am not immersed in this model yet, but it sounds like a nice, 
loosely coupled way to accomplish discovery.  I'll have a look at what 
Zookeeper is doing to get more up to speed.


Just to be clear we/ECF have a pending contribution that allows the use 
of Zookeeper for discovering any/all types of remote services 
providers.  See this bug for details


https://bugs.eclipse.org/bugs/show_bug.cgi?id=301854
and this blog about the contribution:  
http://industrial-tsi-wim.blogspot.com/2010/03/ecf-discovery-how-many-zookeepers-does.html





I see.  I agree that the use of OSGi services for dynamicity is a
very useful thing...and another thing that would make sense to do
within Restlet...assuming OSGi runtime environment.


Naturally.  There has been discussion on the Restlet list of the 
possibility of creating an OSGi "edition" that is more tightly bound 
to OSGi and requires that it be used inside an OSGi runtime.  I 
suspect, from other work I've done, that this needn't be an "edition" 
as other Restlet editions are -- conditionally compiled throughout to 
work in special Java environments, e.g. GWT, GAE, or Android.  IIRC 
that was the last consensus when it came up on the list, too.  I 
suspect that if the appropriate facilities are exposed, all the OSGi 
runtime-dependent aspects can be put in their own bundle(s).  The 
devil being in the details of "the appropriate facilities are exposed" 
... to me this suggests, within Restlet, more reliance on interfaces 
and less on concrete classes, implemented with an a priori awareness 
of what we want higher-level features like ECF discovery and OSGi 
remote services to be able to do with Restlet.


Sounds excellent to me.

Scott

___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] Re: [GSoC] Restlet integration with Equinox

[Rob Heittman]

Inline:

On Sun, Apr 4, 2010 at 6:01 PM, Scott Lewis  wrote:

> My only comment about discovery is that ECF also has a discovery API
> (org.eclipse.ecf.discovery) ...
>

[snip]


> The OSGi remote services spec defines a thing called a 'config
> type'...which is just a String that uniquely identifies a type of remote
> service provider.  ECF maps this 'config type' to identify an ECF IContainer
> type/factory...and this string identified the provider used underneath (e.g.
> ecf.r-osgi.peer, ecf.generic.client, ecf.xmpp.client, etc)...so to use a
> particular provider/protocol to register/publish a remote service all one
> has to do is create a provider with new name, specify it as the config type
> to use when registering a remote service, and that provider will be used.
>

Good.  I am not immersed in this model yet, but it sounds like a nice,
loosely coupled way to accomplish discovery.  I'll have a look at what
Zookeeper is doing to get more up to speed.

I see.  I agree that the use of OSGi services for dynamicity is a very
> useful thing...and another thing that would make sense to do within
> Restlet...assuming OSGi runtime environment.
>

Naturally.  There has been discussion on the Restlet list of the possibility
of creating an OSGi "edition" that is more tightly bound to OSGi and
requires that it be used inside an OSGi runtime.  I suspect, from other work
I've done, that this needn't be an "edition" as other Restlet editions are
-- conditionally compiled throughout to work in special Java environments,
e.g. GWT, GAE, or Android.  IIRC that was the last consensus when it came up
on the list, too.  I suspect that if the appropriate facilities are exposed,
all the OSGi runtime-dependent aspects can be put in their own bundle(s).
 The devil being in the details of "the appropriate facilities are exposed"
... to me this suggests, within Restlet, more reliance on interfaces and
less on concrete classes, implemented with an a priori awareness of what we
want higher-level features like ECF discovery and OSGi remote services to be
able to do with Restlet.

- Rob
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev