This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Currently there is a limitation that a package can belong to only one module. It may be that this is to ensure integrity of the exported public packages (<public-packages> tag in module project.xml) functionality. However this is too limiting. Here is a use case: Say there is a set of Java Beans. These Java Beans are in a package - j.b . The Java Beans are in a jar - jb.jar, that is wrapped in a Library Wrapper Module project - JBLWM. Other modules depend on this Library Wrapper Module. The Java Beans are also used by user application at runtime and exposed as a runtime library to the user project. There are BeanInfo classes associated with the Java Beans. Based on the standard mechanism of BeanInfo lookup of the Introspector they are in the same package- j.b . The Bean Info jar is wrapped in a Library Wrapper module - JBBILWM, which depends on the Java Beans Library Wrapper Module JBLWM. However the Bean Info Classes are not exposed as a library to the user project because the Bean Info is not required for compiling the user project or by the user application runtime. Makes sense?
A valid RFE in general though your particular use case doesn't make sense as far as I know. jb.jar and jbinfo.jar ought to be loaded in the same module since Introspector prefers to find a BeanInfo in the same class loader (using the thread CCL is less reliable). So you can have both JARs loaded in one lib wrapper. The exposure of jb.jar as a user lib is completely independent of that. Not easily implementable without a partial rewrite of the module system, tracked as issue #30971.
Note that there is Introspector.html.setBeanInfoSearchPath http://java.sun.com/j2se/1.5.0/docs/api/java/beans/Introspector.html#setBeanInfoSearchPath(java.lang.String[]) that can help to workaround this particular issue. The restriction is helpfull to optimize current classloading as we can cache the information which classloader loads resources belonging to some package without significant overhead. If we decide to drop this restriction we need to come with something what will be comparably fast. One idea is 'meta-index' similar to mustang's implementation - each classloader has knolwedge what resources can be loaded with it and can quickly reject reqeusts to load other resource (set of prefixes for JAR entries is created).
Yes I realized that the Introspector.setBeanInfoSearchPath() facility will solve that specific problem for us. I suspect we may still have other scenario which requires the original RFE. Will keep you posted.
*** Issue 72807 has been marked as a duplicate of this issue. ***
Seems to have been fixed, I think in #753dd88065e7.
This issue had *1 votes* before move to platform component