Community
Participate
Working Groups
There's several cases where it makes sense to have only resources in a bundle. Various help, documentation, and other such "data only" cases. But, there's no tool-friendly way to implement or enforce this. I believe currently the in resource-only cases there should be no Execution Environment specified in the bundle (since, presumably, it can be used by any). So, there is no way to tell the difference between these Resource-Only cases, and cases where someone has just forgotten to put one in. In fact, from reading the spec, I'm not sure of what is the meaning of having no EE specified? Especially, that is, if Java is contained in the bundle. Does that mean _any_ EE? Seem's that sort of an impossible contract (for Java), since creator of a bundle has no idea of the whole universe of EE's (which is unlimited, if I read it right). In other words, that's the "default" value of EE if its not specified? What's the default behavior? Would any implementations ever want to omit bundles that did not specify an EE? Even Resource-only bundles usually need to go on the classpath so their resources can be found. It's also a bit unclear to me if this enhancement would require an OSGi spec change, or if it's buried in there that implementors can create their own profiles and EE's. Some might consider this an enhancement request, but I consider is a bug or at least a design hole that users and tools are not better accommodated to allow them to explicitly declare the intended use of their bundle. It's always dangerous to assume the absence of something has meaning.
Bundle-RequiredExecutionEnvironment header (B-REE) did not exist until OSGi R3. This means old R1 and R2 bundles did not define the B-REE header. If a bundle does not define B-REE then it means it can work on any EE. This obviously cannot be correct for all bundles but it is the only way to preserve backwards compatibility. A bundle with no code should not define a B-REE header. It is unclear what the runtime would do different with a Resource-Only bundle. The runtime would treat both the same. A classloader does not get created unless a class is loaded from the bundle. If the bundle does not have any classes then a class will not be loaded and a classloader should not get created. Maybe this is a PDE enhancement? If you are creating a resource-only then it seems like the project should not be a Java Project and should not have a classpath container. There are probably other things PDE can do, for example if the project has java code then show an error/warning on missing B-REE header. Reassigning to PDE for consideration.
You already have the option to create a non-Java plug-in project for plug-ins that do not contain code. Flagging a missing EE will be covered under bug 150225. *** This bug has been marked as a duplicate of bug 150225 ***
(In reply to comment #1) > Bundle-RequiredExecutionEnvironment header (B-REE) did not exist until OSGi R3. > This means old R1 and R2 bundles did not define the B-REE header. If a bundle > does not define B-REE then it means it can work on any EE. This obviously > cannot be correct for all bundles but it is the only way to preserve backwards > compatibility. > Tom, your explanation here I think strengthens the argument to provide an EE header such as "resource-only" ... it helps distinguish those "old" ones created without a header, and new ones where it is intentionally "omitted". I am not even saying the runtime would do anything different, but that is not a pre-req for tool friendly specification. Having a Resource-only header would make it easier for developers and bundle IDEs to explicitly state their intent. And, hence, tools could do an even better job of checking if everything was well specified.
CC'ing BJ for his view. Currently the Bundle-ClassPath header has a default value of '.' if it is not specified. It seems that resource only bundles really do not need any Bundle-ClassPath at all. Perhaps OSGi could enhance Bundle-ClassPath to be able to specify that the bundle has no classpath and therefore is a resource only bundle. Either way such a concept raises more questions. For example, if a bundle is specified to be a resource-only bundle should it be able to specify code dependencies (i.e. Import-Package, Require-Bundle etc.). Would this be a silent failure, installation failure, or resolution failure or ... Can fragment bundles add a bundle classpath or code constraints to a resource-only bundle, what about native code etc. We need a very strong requirement to introduce a new catagory of bundle to OSGi. I think tooling can solve this by doing a small amount of inspection on the bundle to see if it has no code and hence is a resource-only bundle.
This issue has come back up in the context of bug 209594.
