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 89629 - OOBE Versionability (aka "headless builds" or "shared libraries")
Summary: OOBE Versionability (aka "headless builds" or "shared libraries")
Alias: None
Product: projects
Classification: Unclassified
Component: Generic Infrastructure (show other bugs)
Version: 6.x
Hardware: All All
: P2 blocker with 2 votes (vote)
Assignee: Milos Kleint
: 89623 122580 (view as bug list)
Depends on: 44035 47498 49637 49638 58080 58356 61227 66275 70876 73375 91723
  Show dependency tree
Reported: 2006-11-19 23:06 UTC by Antonin Nebuzelsky
Modified: 2008-03-25 10:45 UTC (History)
5 users (show)

See Also:
Exception Reporter:


Note You need to log in before you can comment on or make changes to this bug.
Description Antonin Nebuzelsky 2006-11-19 23:06:41 UTC
Currently there is no general system in the IDE for managing where files needed
by your project(s) physically reside.
Comment 1 Jesse Glick 2006-11-20 01:39:21 UTC
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, 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

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.
Comment 2 Milan Kubec 2006-11-20 15:16:52 UTC
*** Issue 89623 has been marked as a duplicate of this issue. ***
Comment 3 Jesse Glick 2006-11-29 19:25:41 UTC
A somewhat old proposal for parts of this is here:
Comment 4 Jesse Glick 2007-02-25 22:12:51 UTC
*** Issue 96488 has been marked as a duplicate of this issue. ***
Comment 5 Jesse Glick 2007-03-26 20:46:37 UTC
Created Wiki page to collect thoughts, notes, status, etc.
Comment 6 David Konecny 2007-12-04 17:47:15 UTC
*** Issue 122580 has been marked as a duplicate of this issue. ***
Comment 7 Jesse Glick 2008-02-25 17:50:03 UTC
I guess some of these issues have been addressed for 6.1 M2.
Comment 8 Milos Kleint 2008-03-25 10:45:10 UTC
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