Bugzilla – Full Text Bug Listing
| Summary: | Plans should be allowed to refer to bundles which are already installed | ||
|---|---|---|---|
| Product: | [RT] Virgo | Reporter: | Alex Blewitt <alex.blewitt> |
| Component: | runtime | Assignee: | Glyn Normington <glyn.normington> |
| Status: | CLOSED FIXED | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P3 | CC: | glyn.normington, tommytcchan |
| Version: | unspecified | ||
| Target Milestone: | 3.5.0.M03 | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| Bug Depends on: | 358441 | ||
| Bug Blocks: | |||
Hi Alex I'm not sure whether this bug is intended to request an enhancement to allow plans to overlap (and to specify existing bundles) or whether it is focussing on the diagnostics in this particular case. If the former is the case, please would you mark this as an enhancement. Regards, Glyn Marking as enhancement for general case of plans overlapping Hi there, I am experiencing the same problem here. In the meantime is there a workaround for this problem? (In reply to comment #3) > Hi there, I am experiencing the same problem here. In the meantime is there a > workaround for this problem? The only workaround is to avoid plans referring to artefacts which area installed before the plan. One way to do this is to install the common artifacts using the initialArtifacts property (described in the Virgo User Guide). Implemented. See bug 358441 for the User Guide changes. |
Build Identifier: 3.0.1 The following plan fails to install into Virgo 3.0.1, with an error complaining about singleton bundle access: <plan name="ecf.plan" version="1.0.0" scoped="false" atomic="false"> <artifact type="bundle" name="org.eclipse.equinox.common"/> <artifact type="bundle" name="org.eclipse.equinox.registry"/> </plan> The error is that the equinox.common already exists: [2011-09-15 18:41:28.711] qtp1302089035-85 <DE0500E> Unable to install application from URI 'file:/H:/VIRGO-~2.REL/work/org.eclipse.virgo.apps.admin.core_3.0.1.RELEASE/upload/ecf.plan'. Ca nnot satisfy constraints for bundle 'org.eclipse.equinox.common' version '3.6.0.v20110523'. Cannot r esolve: org.eclipse.equinox.common Resolver report: The bundle could not be resolved because another singleton bundle was selected. In bundle <o rg.eclipse.equinox.common_3.6.0.v20110523> The bundle could not be resolved because another singleton bundle was selected. In bundle <o rg.eclipse.equinox.common_3.6.0.v20110523> . org.eclipse.virgo.kernel.osgi.framework.UnableToSatisfyBundleDependenciesException: Unable to sati sfy dependencies of bundle 'org.eclipse.equinox.common' at version '3.6.0.v20110523': Cannot resolve : org.eclipse.equinox.common Resolver report: The bundle could not be resolved because another singleton bundle was selected. In bundle <o rg.eclipse.equinox.common_3.6.0.v20110523> The bundle could not be resolved because another singleton bundle was selected. In bundle <o rg.eclipse.equinox.common_3.6.0.v20110523> at org.eclipse.virgo.kernel.install.pipeline.stage.resolve.internal.QuasiResolveStage.proces s(QuasiResolveStage.java:45) However, it should recognise that the bundle already exists, not try and install it a second time, and just use what's there. In this particular case, I want to specify in the plan that common is started before registry. Becaues the kernel already installs (but does not start) the common bundle, I cannot express a requirement in the plan that this bundle must be installed and started. As a result, we run into the other bug mentioned elsewhere. This also prevents the use of any overlapping plans. If I want to implement (say) an ECF host and an ECF consumer, they both have shared dependencies. But I can't install both of them (at least, with 'scoped=false') since the bundles collide. Why can't the plans overlay and allow me to have a similarly named set of bundles in both? How else can I specify that 'common' must be installed, and started, before trying to install registry? Reproducible: Always Steps to Reproduce: 1. Install plan above into virgo 3.0.1 (jetty) 2. See it fail 3. There is no step three