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

Summary: OOBE Versionability (aka "headless builds" or "shared libraries")
Product: projects Reporter: Antonin Nebuzelsky <anebuzelsky>
Component: Generic InfrastructureAssignee: Milos Kleint <mkleint>
Status: RESOLVED FIXED    
Severity: blocker CC: dkonecny, kirillkh, mmirilovic, pjiricka, pzajac
Priority: P2 Keywords: API, PLAN, UI, UMBRELLA
Version: 6.x   
Hardware: All   
OS: All   
URL: http://wiki.netbeans.org/wiki/view/OutOfBoxVersionability
Issue Type: ENHANCEMENT Exception Reporter:
Bug Depends on: 44035, 47498, 49637, 49638, 58080, 58356, 61227, 66275, 70876, 73375, 91723    
Bug Blocks:    

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, 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.
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:

http://java.netbeans.org/Proposals/Project/project_shareability.html
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