Don't add parent packages, only the ones that are actually present

[bosschaert]

Previously the code added all the packages, also packages which were just found as parent directories in the Jar file. As packages aren't hierarchical this isn't correct. Only packages in which .class files are found should be added.

[tjwatson]

What problem does this pose? I worry about packages they may contain resource only.

[karlpauls]

I think the actual problem is that it currently adds directories - that makes it so that packages get claimed for a bundle that actually only has a sub-package. Let's say we have a bundle A with org/foo/Foo.class and bundle B with org/foo/bar/Bar.class. We don't want bundle B to be identified for the org.foo package (only for the org.foo.bar package). In other words, I guess I agree that the requirement for a .class file is too strong - it would be better to just require something else than a dir (i.e., filtering out all directories).

[tjwatson]

I see it adding too many directories with only other sub-directories (no files) , but I am unclear what observable consequence there is to this.

Refreshing my memory of this, the code only reads from this map packageToAtomosContent in the method org.apache.felix.atomos.impl.base.AtomosBase.getAtomosKey(Class<?>). So it will only really be used for looking up a package name that actually has a loaded Class. What I think the observable consequence may be is when a parent package is contained in another bundle and the order is such that the bundle with the child package is processed first and there for takes over the map entry for that package name. Is that something you all ran into when discovering this issue?

[rotty3000]

when a parent package is contained in another bundle and the order is such that the bundle with the child package is processed first and there for takes over the map entry for that package name.

I've observed this exact problem when bnd's JPMS plugin was over stocking a module description with "packages" of empty dirs. However, you need to account for both resources and class files alike when computing what is a package and what is not.

.. and yet even this can go wrong. Think of jars which include schema files from other projects (looking at you JavaEE/Jakata and friends) so you should leave some form of escape hatch.

[karlpauls]

Yes, the issue is that it is used for the lookup of the bundle that provides a given class (via FrameworkUtils). So in my scenario above, if bundle B gets the spot for org.foo it is returned for the bundle lookup of the Foo.class via FrameworkUtil.

[tjwatson]

Can we change this to be if (!s.endswith("/") && s.contains("/")) {

In other words all paths that are not directories (don't end with "/") and are not part of the default package (paths with no "/" at all).

[bosschaert]

I think that would probably work yes.