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 no general system in the IDE for managing where files needed by your project(s) physically reside.
Currently there is no general system in the IDE for managing where files needed by your project(s) physically reside. Any serious team will want to maintain everything needed for development and production in a version-controlled source tree which can be built from scratch on a headless build server. While this is possible in current versions of NetBeans if you know what you are doing, there are some obstacles, including: 1. Some software bundled by the IDE (e.g. Java EE libraries, or special Ant tasks) might need to be referred to by your project(s), yet is not in its source tree. If the project has been opened in an IDE, private.properties links to these files, but that is no use for continuous builder machines, which would require manual setup: you need to copy the right files to the build server and define various properties. Or you need to move these files into the versioned tree and point to them from the project properties, and manually update them with newer releases when appropriate. 2. You can use the same (relatively located) copy of a JAR in several projects and version it. But, if you want to associate sources and Javadoc for development purposes, you still need to make a library definition which duplicates the JAR location - and this definition cannot be shared with other developers. 3. For projects with generated build scripts (build-impl.xml), the IDE will create one copy of the generated script per project, even if several projects share a versioning root and could in principle share one copy of the script. This item is complicated by the fact that some project.xml modifications actually change build-impl.xml currently. 4. If you require a particular JDK to build the project, just as with libraries it is tricky to configure this in a way that satisfies both in-IDE usage and continuous build server usage. There may be similar issues with Java EE servers and API artifacts. 5. If you add a new library, subproject, etc. to a project, the IDE will probably store a relative location as you would expect. But there is no way using the GUI to correct it if it did not, nor is there any warning about hardcoded absolute filesystem paths in an otherwise fully versionable disk area.
*** Issue 89623 has been marked as a duplicate of this issue. ***
A somewhat old proposal for parts of this is here: http://java.netbeans.org/Proposals/Project/project_shareability.html
*** Issue 96488 has been marked as a duplicate of this issue. ***
Created Wiki page to collect thoughts, notes, status, etc.
*** Issue 122580 has been marked as a duplicate of this issue. ***
I guess some of these issues have been addressed for 6.1 M2.
1,2,4 and 5 are completely or partly (in case of 4) resolved by the "sharable libraries" effort. 3. is not done and I don't think it's relevant or possible to do with the ant build extending APIs that we have since 6.0. closing as fixed in 6.1