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.

Bug 76979 - Creator complib requirements
Summary: Creator complib requirements
Alias: None
Product: projects
Classification: Unclassified
Component: Libraries (show other bugs)
Version: 5.x
Hardware: All All
: P1 blocker (vote)
Assignee: Tomas Zezula
Keywords: UMBRELLA
Depends on: 76978 44035 55371
  Show dependency tree
Reported: 2006-05-27 00:20 UTC by _ edwingo
Modified: 2006-10-23 16:40 UTC (History)
2 users (show)

See Also:
Exception Reporter:


Note You need to log in before you can comment on or make changes to this bug.
Description _ edwingo 2006-05-27 00:20:51 UTC
This issue collects in one place requirements for NetBeans related to the
complib feature of Creator and it provides background information for those

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.


+ Provide a public API to manipulate library definitions. This includes
  creating and modifying the libdefs.

+ 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

+ 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.

+ 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

+ 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.
Comment 1 _ edwingo 2006-05-27 01:32:53 UTC
The issue "Allow library definitions to be stored within projects themselves"
that I was looking for above is
Comment 2 Jesse Glick 2006-05-27 02:44:00 UTC
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).
Comment 3 _ edwingo 2006-06-01 22:46:03 UTC
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.

Comment 4 Tomas Zezula 2006-06-02 07:21:20 UTC
Added Standa to cc to evaluate the requirement for component palette from Jun 1
Comment 5 Stanislav Aubrecht 2006-06-02 08:45:23 UTC
the common palette has api to show/hide items and categories as needed
(interface PaletteFilter) and to remove them permanently (simple Node.destroy())
Comment 6 Tomas Zezula 2006-09-11 10:55:42 UTC
Checking in apichanges.xml;
/cvs/projects/libraries/apichanges.xml,v  <--  apichanges.xml
new revision: 1.5; previous revision: 1.4
Checking in src/org/netbeans/api/project/libraries/;
new revision: 1.9; previous revision: 1.8
Checking in src/org/netbeans/api/project/libraries/;
new revision: 1.7; previous revision: 1.6
RCS file:
Checking in src/org/netbeans/modules/project/libraries/;
initial revision: 1.1
RCS file:
Checking in src/org/netbeans/spi/project/libraries/;
initial revision: 1.1
Checking in src/org/netbeans/spi/project/libraries/support/;
new revision: 1.4; previous revision: 1.3
Checking in
new revision: 1.6; previous revision: 1.5
Comment 7 Tomas Zezula 2006-09-11 11:03:06 UTC
Fixed all except of: "Provide a public API to manipulate library references
which are stored in projects"
Tis requirement is covered by an issue:
And the following specification: