Community
Participate
Working Groups
The org.eclipse.eclipse.link.jpa had an optional dependency on the weaving package. The recent org.eclipse.gemini.jpa-1.0.0.M4 appears to have a mandatory dependency on org.eclipse.gemini.jpa.weaving-1.0.0M4. This causes problems with Virgo. Because Virgo installs/uninstalls bundles fairly frequently, if there is a bundle which depends on the system.bundle, then uninstalling that can cause the system to stop. Therefore, it's necessary when using Virgo to not install the weaving support. If the bundle is changed such that the import is marked as optional, then there won't be a need to co-deploy them, assuming that the JPA support is still optional. Import-Package: ...,org.eclipse.gemini.jpa.weaving;resolution:=optional,...
The problem is that the weaving bundle isn't really an optional dependency in the typical meaning of the term. It is only optional when weaving is not enabled. When weaving is enabled then the bundle is required. If we were to declare it optional then weaving would only work if the gemini weaving bundle happens to have been installed before the gemini jpa bundle has been resolved. Basically a crap shoot that I don't think people will like much. A better solution, though, would be to make use of the new Weaving Service, which precludes the need for the gemini weaving bundle to be a system.bundle fragment. Have entered bug 345313 to track that enhancement.
Will be properly fixed when enhancement 345313 is added.
Whilst I agree with the suggestion in the related bug (and the fact that this won't be fixed) I disagree with your inference of 'optional', since this is precisely what the point of optional means. A non optional dependency means none of this code can be used without the dependency present An optional dependency means that some of this code can be used, but perhaps with limited or reduced functionality In this case, being able to ship without this is fine; what it does is restrict the use of weaving. It shouldn't be the case that this is needed for all environments, but a documented that if not present then weaving cannot be enabled. Indeed, you could make it a runtime error for bundles which demanded weaving to fail if the weaving bundle wasn't present.
> A non optional dependency means none of this code can be used without the > dependency present right, and I understand your point that it isn't the case when weaving is disabled. But this is precisely the case when weaving is enabled, which is (or should be) the default case. > In this case, being able to ship without this is fine; what it does is restrict > the use of weaving. It shouldn't be the case that this is needed for all > environments, but a documented that if not present then weaving cannot be > enabled. Indeed, you could make it a runtime error for bundles which demanded > weaving to fail if the weaving bundle wasn't present. So isn't this really just a tradeoff? Either we make it optional so the applications that do not require weaving can do without the extra bundle, but that means we either leave weaving to only work at the mercy of the startup sequence or have to reinvent a dependency mechanism in code (which OSGi is supposed to be providing) when weaving is enabled, or we make it easier for the weaving applications and use the OSGi mechanism of dependency, but force applications that are willing to sacrifice weaving to still be required to install the weaving bundle. It sounds like you might be in favour of the first, and I find myself leaning toward the second. Is this right?
I believe that the dependency should still be optional. This allows it to work for the {disabled, not installed} case, which is currently not possible. A suitable message can be logged in the {enabled, not installed} state since this doesn't work. By making it optional, you enable a situation that isn't possible at the moment. By keeping it as mandatory, you're not enabling a situation that isn't possible. An optional install can still have it installed (and thus will work).
