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.
I have the following scenario: MainProject which dependends on 2 projects: Pro1, and Pro2. Pro1 depends on some jar files: x.jar, y.jar Pro2 depends on some jar files: z.jar, w.jar After the build, the dist folder is created having the following structure: dist |_ lib | |_ Pro1.jar | |_ Pro2. jar |_ MainProject.jar Now, the thing is the jars on which Pro1, and Pro2 depend are missing. I checked the manifest files for Pro1.jar, and Pro2.jar. I noticed that the Pro1.jar' manifest has the classpath set as: Class-Path: lib/x.jar lib/y.jar Pro2.jar' manifest has the classpath set as: Class-Path: lib/z.jar lib/w.jar Of course that the main application would not work that way. I found 2 ways to workaround this, but having the automatic distribution functionallity, I would expect it to work. Here are the 2 workarounds: Workaround 1: A. Change the manifest files, so that we don't have to add another lib folder in the existing folder: Class-Path: x.jar y.jar Class-Path: z.jar w.jar B. Add the missing jars (x, y, z, w) to the automatically generated lib folder. Workaround 2: A. Create a lib folder inside the automatically generated lib folder. B. Add the missing jar files (x, y, z, w) to the new lib folder. Any other ideas? This should be fixed.
Workaround is for MainProject to include [xyzw].jar as at least runtime dependencies (see Libraries panel). See issue #47507 - NetBeans Java SE projects do not perform transitive dependency management. The dist folder is also intended only as a convenience for simple projects, not as a substitute for a project-specific Ant target to create a complete distribution in an idiosyncratic format. Maven may be the better choice for large project setups where you want full dependency management. Then you can pick a tool for creating a self-contained runnable: JarJar, Classworlds, etc. Plain old Java SE execution does not define any standard way of packaging dependencies; JNLP ("Web Start") comes closer, but does not define any interaction with a development & build system. JSR 294 _may_ improve the situation. *** This bug has been marked as a duplicate of bug 47507 ***
Thanks. I didn't mention your workaround on purpose, because it's more ugly, due to its nature, having to change the project's settings. I think that you can find such opinions in the #47507 issue. It's a good thing though that the target is set for 6.9 :-)