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.
When working in a team, it's hard for everyone to be using the same snapshot of the libraries because you have no way to export the bundles you created from "Tools" -> "Libraries" So I would ask for the following 2 items: i. Support the use of relative paths when creating libraries for the classpath, sources and javadoc tabs ii. Allow exporting a collection of libraries to some file that another user of the same team/project can import.
You can already keep your libraries in a collocated directory, either a subdir of the project or a sister directory for use from multiple projects. Then just keep this libraries dir in your version control system and you should be all set. http://wiki.netbeans.org/FaqRelativePaths
(In reply to comment #1) > You can already keep your libraries in a collocated directory, either a subdir > of the project or a sister directory for use from multiple projects. Then just > keep this libraries dir in your version control system and you should be all > set. > > http://wiki.netbeans.org/FaqRelativePaths Seriously, no, because that works for libraries, the jar containing the class themselves but not the source jars and not the javadoc zip folders. I can see why you would like to get rid of this but this solution has always been inferior to begin with.
In my point of view, when we are multiple developers working on a project, the way that "Tools -> Libraries" work is much better than adding jar/files directly in the project. It's very useful to hide the details of a 3rd party library. You can use a different version or complement your own documentation without having to disturb other developers. But it doesn't seem to be used as much. For instance, how can I make a backup of this without having to fiddle with the underlying files? When I move to a different workstation, I either have to bring my whole ~/.netbeans directory or recreate all my Libraries in this window. I really wished we had a tool to back this up. At the same time, supporting relative paths is not really an option, because I rarely have the same absolute path on both my Unix and Windows workstations.
(In reply to comment #2) > that works for [...] the jar containing the class > themselves but not the source jars and not the javadoc zip folders. Not true. You can keep relative references to source and Javadoc ZIPs as well. To demonstrate, you need only: 1. Create a Java SE project. 2. Set the Libraries Folder to ./lib and accept the offer to copy existing libs there. 3. Make a JUnit 4 test. 4. Go to Source on @BeforeClass - you will be in org/junit/BeforeClass.java in .../lib/junit_4/junit-4.5-src.jar. 5. Help > Javadoc References > JUnit 4.5 will similarly show http://127.0.0.1:8082/resource/jar%3Afile%3A/.../lib/junit_4/junit-4.5-api.zip!/overview-summary.html
(In reply to comment #3) > You can use a different version or complement your own documentation > without having to disturb other developers. Any definitions present in nblibraries.properties can be supplemented or overridden by nblibraries-private.properties, which will be excluded from version control.
I believe Jesse is right, there is no reason to get rid of this issue as what you request is already implemented, IMO. Using sharable libraries [1] it is much cleaner solution than "exporting libraries", no matter how it is implemented. 1 Right-click your existing project 2 Select "Libraries" section 3 Browse for a folder for "Libraries folder" using the "Browse" button From now on, you share the libraries (not just JARs) with the project. If you now open Tools>Libraries, you can see the combobox (Libraries location) where you can manage the libs for the particular project... Anyone who checks out libs from the VCS can see the same libraries... [1] http://blogs.sun.com/tm/entry/project_with_sharable_libraries_aka