| RE: [equinox-dev] Re: [p2-dev] who should declare dependencies on ds? |
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-bounces@xxxxxxxxxxx [mailto:equinox-dev-bounces@xxxxxxxxxxx] 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 <tjwatson@xxxxxxxxxx>
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.doc.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
manifest so even if we specified these today I don't think it would really help
in ensuring a DS runtime is provisioned by p2. Perhaps we should consider
adding that to p2?
Also note that the OSGi alliance is currently looking at providing a standard
way for declaring generic capabilities and requirements for a future core
specification. We should keep an eye on this space and feed any additional
requirements we may have to OSGi in this area.
Tom
Jeff McAffer ---04/01/2010 11:46:32 AM---It should be up
to the system integrator. Actually, there should be metadata (in p2) that
expresses the need for various servic
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
It should be up to the system integrator.
Actually, there should be metadata (in p2) that expresses the need for various
services to be present to make the integrator's job easier but ultimately
inclusion/activation/... are in the eye of the beholder. So we should not cod
classpath (bundle or package) dependencies, rather we need more markup in p2
metadata to capture these non-classpath-related dependencies.
More detail: In this case you could declare a
package dependency on the ds package but that will only get you the interfaces
and not the implementation. The producer could similarly declare a bundle
dependency on the Equinox ds bundle. This is short sighted as there are other
DS implementations. Various p2 features could include the Equinox DS bundle.
This is better but suffers from the same problem--that feature would not be
usable with other DS implementations.
Note that the problem is a friend of the HTTP
service, Help system and myriad of other situations where people need a service
to be there but there is no clear declaration of that dependency.
Note also that simply having DS there is not
enough. It needs to be started. This is a product/launch level concern (i.e.,
the DS bundle can/should not say that it should always be started).
So, unless the p2/ds problem is burning, it
would be better to address the underlying issue than ad hoc addressing of the
symptoms.
Jeff
On 2010-04-01, at 12:21 PM, Susan Franklin
McCourt wrote:
We
currently use ds in p2 to declare most of our services.
Yet we don't have any particular bundle that declares a dependency on ds.
I can justify this in some respects - theoretically there could be clients that
consume the p2 bundles, declare their own services (using ds or dynamically)
and thus don't care about getting the default service registrations. However
this is not typical usage. Most people would expect to get the ds-declared
services, and right now they only get cryptic errors or failed launches if they
aren't using our features or product files and don't know to include ds.
For example, in a recent bug [1] , someone was getting a confusing error
because we forgot to include ds in the .product file for an example. We fixed
it by including ds in the product file.
My question is - is this the right fix?
It feels a little strange that a consumer that doesn't declare any services
with ds still has to know that the bundles it is using declare their services
this way.
Is it intentionally left up to the configurer of the system to ensure ds is
included in the running target? Or should the bundles that declare services
with ds be requiring the ds bundle?
susan
[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=307558
_______________________________________________
p2-dev mailing list
p2-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/p2-dev
_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev
_______________________________________________
p2-dev mailing list
p2-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/p2-dev
_______________________________________________
p2-dev mailing list
p2-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/p2-dev