[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
AW: [equinox-dev] Re: [p2-dev] who should declare dependencies on ds?
|
I think the Import-Service Header in the manifest -
together with obr and bindex - would work - but its
deprecated...
rgds, michael
This is the thing about decoupling bundles with services...
Eggs do not depend on flour; they know nothing about flour. Flour knows
nothing about eggs. We need some kind of knowledge that lives outside of the
ingredients -- i.e., a recipe -- in order to make pancakes.
Rgds,
Neil
On Fri, Apr 2, 2010 at 9:57 PM, Jeff McAffer
<jeff@xxxxxxxxxxxxxxxxx>
wrote:
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.JeffOn 2010-04-01, at 12:21 PM, Susan
Franklin McCourt wrote:
_______________________________________________
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
_______________________________________________
equinox-dev
mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev