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 94896 - Projects should facilitate multiple dependency integration...
Summary: Projects should facilitate multiple dependency integration...
Status: RESOLVED DUPLICATE of bug 44035
Alias: None
Product: projects
Classification: Unclassified
Component: Libraries (show other bugs)
Version: 5.x
Hardware: All All
: P1 blocker (vote)
Assignee: Tomas Zezula
Depends on:
Reported: 2007-02-07 22:29 UTC by predatorvi
Modified: 2007-02-07 23:05 UTC (History)
0 users

See Also:
Issue Type: DEFECT
Exception Reporter:


Note You need to log in before you can comment on or make changes to this bug.
Description predatorvi 2007-02-07 22:29:43 UTC
I am entering this because it is causing me a lot of headache and all attempts
to find answers on the mailing lists or documentation of "best-practices"
regarding project setup have been fruitless.

I am finding it difficult to wrap my head around groups of inter-related
projects with multiple dependencies in order to get the following functionality:

1) Command-line build from a single VCS (subversion in my case) checkout without
additional complex configuation of libraries.  I want to be able to run ant and
have it build.  Using Netbeans libraries does NOT solve this because I can't
guarantee (and dont' want to force) every system to have NetBeans installed.

2) Building/debugging a top-level project with dependencies on one or more
sub-projects with dependencies on potentially other sub-projects and or
third-party Java Class Libraries.  I would like:
   a) all the dependent JAR files to be automatically included in the top-level
project class path, and
   b) allowing 1a) above without modifying the project itself. 

3) Distributing a top-level project with dependencies on one or more
sub-projects with dependencies on other projects and or third-party Java Class
Libraries so that all the required libraries are included in the final
distribution without a lot of extra hand-tweaking of the build script.

4) Allow dependencies to be referenced using relative paths from projects.

- I have both web app and a stand-alone Java application that have a pluggable
architecture.  The core "engine" allows modules to be loaded dynamically from
the classpath.  Different developers work on different plug-in's and need to
debug them.  However, doing so requires explicitly changing the top-level
project to not only include the sub-project(s) (which I could live with if that
was it), but also all the dependent libraries.  Often the top-level project gets
checked in inadvertently with these dependencies.  However, other developers
don't need them as they work on other and when they update from Subversion, they
have to continually resolve conflicts created.

This same issue occurs because of the path differences between developer
machines even for those working on the same project(s) if the dependencies were
checked out of source control in different locations.

- Our source is available within our organization for people to build and use. 
I spend a lot of time getting others to install and configure NetBeans for them
to be able to successfully build, even though there is supposed command-line
build support via basic ANT invokation. I could directly include all libraries
for all sub-projects in the top-level project, but that gets to be a nightmare
and I lose the coupling of source code and docs to the JAR files.

- Update NetBeans to (optionally?) include in the top-level project ALL
dependent project JAR's AND their dependencies automatically without excplicit
inclusion. (Fixes building/debugging issues)

- Make libraries project-specific and relative to the project paths.  This would
allow me to build a self-contained project-subproject heirarchy so command-line
builds will work without a lot of additional configuration.

- Possibly -- allow loose coupling of sub-projects or libraries in the local IDE
for one-off build and debug sessions.  Another term could be "virtual
dependencies" that are not saved with the project(s) directly but maintained by
the IDE.  Neither project should incur any changes that (if checked in) would
break someone else's project dependencies.

- Create a best-practices document online to explain much of the limitations
and/or work-arounds to setup a complex project heirarchy.

Some of this may be able to be done now, I just can't figure out the best way 
do it without sacrificing some other need and our projects and collaboration
points are growing.

As a side note:  I wish you would make Mailing lists for each major version of
NetBeans so I don't have to wade through 5 years worth of posts about NetBeans
3.x in order to distill a solution for my issue with NetBeans 5.x.
Comment 1 Jesse Glick 2007-02-07 23:05:34 UTC
All these are well-known. To be clear, the NB library manager is intended only
for quick set up of simple cases; it is not appropriate for large multi-project
environments. Consider using something like Maven (for which there is some
NetBeans integration currently available, though much more work remains to be done).

(1) and (4) are issue #44035.

(2) is issue #47507.

(3) should more or less already work, in that all JARs in the classpath of the
main project are copied to the dist folder. For more subtle distribution
mechanisms, you are on your own.

*** This issue has been marked as a duplicate of 44035 ***