| Phil, I am completely sympathetic with your case and, BTW, thanks for adopting p2 early. Your suggestion for more doc makes sense. There should likely be a big "get and start DS" topic in several places. Could you enter a bug for that? Likely in Equinox/Compendium area of bugzilla.
For completeness, this is not an issue specific to p2 rather whoever uses DS. It happens that p2 is one of those parties. I don't know who all uses DS but it has been part of the RCP feature since 3.5 at least. If your app is includes/depends on the RCP feature then you should get DS with no additional action. This was really my point. It should be up to higher level constructs to say "hey, to support this scenario, we are going to put together these bundles and ...". That is what we did in the RCP feature. In light of that, it would not be unreasonable to say that the p2 features should spec a dependency on the DS bundle. If that were to happen, I would use "require" not "include" to allow for flexibility in the underlying deployment.
Note that DS still needs to be started (and typically with a low start level). I recall last year lots of discussion around having PDE do this automatically for people but do not remember the outcome of that.
Jeff
On 2010-04-02, at 9:58 AM, Phil Borlin 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 11:50 AM, 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
<graycol.gif>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
<ecblank.gif>
From: | <ecblank.gif>
Jeff McAffer <jeff@xxxxxxxxxxxxxxxxx> |
<ecblank.gif>
To: | <ecblank.gif>
P2 developer discussions <p2-dev@xxxxxxxxxxx> |
<ecblank.gif>
Cc: | <ecblank.gif>
Equinox development mailing list <equinox-dev@xxxxxxxxxxx> |
<ecblank.gif>
Date: | <ecblank.gif>
04/01/2010 11:46 AM |
<ecblank.gif>
Subject: | <ecblank.gif>
[equinox-dev] Re: [p2-dev] who should declare dependencies on ds? |
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:
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev
_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev
|
