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.
Related to bug 180707. 1. Create a new Java class library - Lib1 2. Add one of the libraries distributed with the IDE (e.g. Beans Binding) to the classpath of Lib1 3. Build Lib1 4. Create a new Java class library - Lib2 5. Add Beans Binding to the classpath of Lib2 6. Add Lib1 to the classpath of Lib1 (through "Add Project...") 7. Build Lib2 The dist directory structure of Lib2 is the following: lib +-- Lib1.jar +-- beansbinding-1.2.1.jar Lib2.jar Lib1.jar contains the following in the manifest: Class-Path: lib/beansbinding-1.2.1.jar I.e. it refers to file lib/lib/beansbinding-1.2.1.jar, which does not exist.
Correction: 6. Add Lib1 to the classpath of Lib2 (through "Add Project...")
Yes, the copylibs was designed for a bit more simple use cases as it was a fast solution for single release which exists nearly for 10 releases. The original idea was not to put the libraries directly into the dist folder, but it seems that we well need to change it to allow transient dependencies. It will be not very nice but the other solution (changing ClassPath attr of libraries during copy) is even more evil.
After reading David's last comment in the issue #105927 I am a bit confused as this is in contradiction to David's comments in issue #180707.
Issue 105927 is about IDE internal compilation behaving differently from javac and issue 180707 is about IDE generating jars with ClassPath entry in manifest. I don't see any contradiction - these are different usecases, no? We should generate ClassPath entry only in some cases - eg. Java App project - and I'm saying that anytime user adds a jar containing ClassPath entry to a project then IDE compilation must work the same way javac does.
>We should generate ClassPath entry only in some cases - eg. Java App project Not the case of the gf, where the lib contains the Class-Path attr. > - and I'm saying that anytime user adds a jar containing ClassPath entry to a project then IDE compilation must work the same way javac does. It's quite simple to add it on Java api + source level, I am having working implementation of this. The problem is that build scripts are not handling transitive dependencies as the build system was not designed to do this, java will see recursive project dependencies but the build sys is not able to build them, also copying of transitive refs will not work, etc.
re. "Not the case of the gf, where the lib contains the Class-Path attr" - I see what you mean now. That lib is generated by GF team - in order to use GF embeddable ejb container in your unit tests you have to add some GF jars to your test classpath; the problem is that you have to add several dozens of GF internal JARs (totalling about 45MB) and as a workaround GF team decided to build this 3kB jar which references all these jars via ClassPath attribute. They considered building a jar which would contain class closure of all required classes but it was still HUGE. To me this is a workaround which may work for GF but which is causing lots of other problems, eg. project cannot be made sharable.
OK, I will not do the copylibs and Class-Path attr for libraries (project with no main class) as David requested.
Fixed in jet-main 03c53d647a60
Integrated into 'main-golden', will be available in build *201002250200* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/03c53d647a60 User: Tomas Zezula <tzezula@netbeans.org> Log: #180886:Unsuitable value of Class-Path manifest attribute in a transitive library scenario
Integrated into 'main-golden', will be available in build *201002260200* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/03c53d647a60 User: Tomas Zezula <tzezula@netbeans.org> Log: #180886:Unsuitable value of Class-Path manifest attribute in a transitive library scenario