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.
This issue collects in one place requirements for NetBeans related to the complib feature of Creator and it provides background information for those requirements. Creator has a component extension mechanism which uses complib files which is essentially a package (similar to a war) containing a collection of JavaServer Faces related components that are provided by third-parties. A complib contains jars that contain the components themselves as well as related information such as design-time and meta-data files. The jar files in the complib come pre-built from third-parties and source code and javadoc are optional. Upon import, a complib is expanded into a directory and the contained jars are accessed by projects through a modification of the NetBeans library code which will no longer be allowed. In NetBeans, a library definition (libdef) is stored in the userdir and a library reference (libref) that points to a libdef is stored in a project. The NetBeans library mechanism was selected so that source code and javadoc can be attached to jar files. Requirements: + Provide a public API to manipulate library definitions. This includes creating and modifying the libdefs. http://www.netbeans.org/issues/show_bug.cgi?id=55371 + Allow library definitions to be stored within projects themselves. This allows projects to be self-contained as it can be zipped up and sent to a co-worker. Currently, libdefs live in the userdir so this is not possible. I have heard there is an issue filed for this, but I can't find it. + Provide a public API to manipulate library references which are stored in projects. I believe, there is a "packaging" flag that is stored with the libref and not with the libdef. The API needs to be able to control this flag since some jars are deployed and some are not. http://www.netbeans.org/issues/show_bug.cgi?id=55371 + NetBeans needs to allow a separate design-time classpath that is separate from complie-time and runtime (packaged flag) classpaths to limit the scope of references available during code-completion. Currently, since there is no concept of a design-time classpath, the BeanInfo classes are included in the complie-time classpath. Thus when a user is working in the java editor and uses code-completion, BeanInfo classes incorrectly appear. BeanInfo classes are part of the design-time classpath and are not deployed, ie. packaged, and so an app that uses them will fail when deployed. http://www.netbeans.org/issues/show_bug.cgi?id=76978 + I've heard that this may be an issue. Third-parties typically write BeanInfo classes in the same package as the beans themselves so NetBeans should support this common case. http://www.netbeans.org/issues/show_bug.cgi?id=71524
The issue "Allow library definitions to be stored within projects themselves" that I was looking for above is http://www.netbeans.org/issues/show_bug.cgi?id=44035.
Issue #71524 is applicable only to classes in modules. Should have no effect on JavaBeans libs used e.g. in the form editor (if it does, it's a form editor bug).
Additional requirement which may already be met: NetBeans palette needs to provide API to allow items to be hidden or removed easily from the palette. Background: Creator 2 contains complib versioning bugs that make complibs difficult to use. Complibs have version numbers. When a complib with a particular version is used in a project, then that project should not use components from a complib in the same namespace but with a different version. This requires the palette to be able to hide components that are not useable in the project.
Added Standa to cc to evaluate the requirement for component palette from Jun 1 21:46:03.
the common palette has api to show/hide items and categories as needed (interface PaletteFilter) and to remove them permanently (simple Node.destroy())
Checking in apichanges.xml; /cvs/projects/libraries/apichanges.xml,v <-- apichanges.xml new revision: 1.5; previous revision: 1.4 done Checking in src/org/netbeans/api/project/libraries/Library.java; /cvs/projects/libraries/src/org/netbeans/api/project/libraries/Library.java,v <-- Library.java new revision: 1.9; previous revision: 1.8 done Checking in src/org/netbeans/api/project/libraries/LibraryManager.java; /cvs/projects/libraries/src/org/netbeans/api/project/libraries/LibraryManager.java,v <-- LibraryManager.java new revision: 1.7; previous revision: 1.6 done RCS file: /cvs/projects/libraries/src/org/netbeans/modules/project/libraries/LibraryAccessor.java,v done Checking in src/org/netbeans/modules/project/libraries/LibraryAccessor.java; /cvs/projects/libraries/src/org/netbeans/modules/project/libraries/LibraryAccessor.java,v <-- LibraryAccessor.java initial revision: 1.1 done RCS file: /cvs/projects/libraries/src/org/netbeans/spi/project/libraries/LibraryFactory.java,v done Checking in src/org/netbeans/spi/project/libraries/LibraryFactory.java; /cvs/projects/libraries/src/org/netbeans/spi/project/libraries/LibraryFactory.java,v <-- LibraryFactory.java initial revision: 1.1 done Checking in src/org/netbeans/spi/project/libraries/support/LibrariesSupport.java; /cvs/projects/libraries/src/org/netbeans/spi/project/libraries/support/LibrariesSupport.java,v <-- LibrariesSupport.java new revision: 1.4; previous revision: 1.3 done Checking in test/unit/src/org/netbeans/api/project/libraries/LibraryManagerTest.java; /cvs/projects/libraries/test/unit/src/org/netbeans/api/project/libraries/LibraryManagerTest.java,v <-- LibraryManagerTest.java new revision: 1.6; previous revision: 1.5 done
Fixed all except of: "Provide a public API to manipulate library references which are stored in projects" Tis requirement is covered by an issue: http://www.netbeans.org/issues/show_bug.cgi?id=44035. And the following specification: http://java.netbeans.org/Proposals/Project/project_shareability.html