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 is a top-level task to track the entire subsystem progress. The goal is to allow module writers and users to package related resources, such as 3rd library .jars, accompanying documentation and/or source code, together to a single piece. The library definition can be then reused in several projects allowing easy configuration of the build system. As an example, one could take Xerces project from Apache.org, which contains some classes, source code for informative purposes and reference documentation. This all will be packaged up into a "Xerces XML parser" library. When inserted into the project, compiler, execution, javadoc search and other services should honour all the included resources.
Adjusting milestone for planning
Real client (similar to mentioned example) is XML module. I would like to create XML-APIs library which could contain API for compile time, API+impl for run/debug time, API Javadoc and sources for debug time. [Issue #27167]
Could the library also cover ParserDB files, i.e. code completion for library API?
WOW! Never thought of that. I think it might - although it means for us to provide a generic way how to put "some stuff" into the library's definition. I am CC:ing Mato, so he can comment (or just sign off, it seems as a ridiculous idea :-)
If I understand it correctly, then the main goal of including parser DB(s) into the library is to share the DB(s) among projects and performance reason (the resource needn't be parsed to create a parser DB for it). New design of javacompletion infrastructure is able to distinguish global parser databases and project sensitive parser DBs. Global parser databases are physically stored in NetBeans install folder or userdir folder /system/ParserDB. The project sensitive DBs will be stored in project folder. If module writer wants to add some parserDB into the global level, he can create netbeans/system/ParserDB folder in the CVS and put there parserDBs as editor module does it with jdk DBs or use ant to create this automatically during building process as appisupport module does it. (apisupport/apidocs/build.xml - target name "parser-db") The problem will raise in the case that global parser DBs should be shared only for several projects and not for all. In this case the solution you have proposed can be really usefull. OTOH, if parser DB will not be presented in the shared library the following problem can occur: Completion database parser will take into the consideration the designtime classpaths. If some designtime classpath will be shared via this library among several projects, it simply appears in all these projects as a resource. In this case there is a risk, that the database for this classpath will be created in each project, that shares it. Here I propose some flag to distinguish shared resource, the parser DB can be done as global in this case.
*** Issue 32632 has been marked as a duplicate of this issue. ***
Libraries requirements summary is at <http://projects.netbeans.org/libraries/requirements.html>.
Support for non-Java libraries was raised in issue #36444.
The projects prototype has been canceled. For more details see http://www.netbeans.org/servlets/ReadMsg?msgId=619519&listName=nbdiscuss