Latest nb 6 build.
Create a java project, and in the "Libraries" node, add a jar that contains an
where foo.jar is in the same directory of this jar.
If foo.jar defines the class com.acme.Foo
try to add
in the main clas of your project.
You'll see a red icon on the java source editor saying com.acme.Foo is not defined.
But build the project: it can build since javac is using the entire classpath
(including manifest entries for Class-Path)
This is a bummer for GlassFish V3 as the javaee-5.0.jar is only a empty jar that
defines impl dependent jars.
same for web app projects...
*** Issue 105928 has been marked as a duplicate of this issue. ***
The transitive dependencies are supported by JDK 5.0 javac and newer, not in
older versions, the IDE supports platforms staring from JDK 1.2. The project
compile class path will need to analyze the active platform and transitively the
jar file manifests. Of course the IDE will need to listen on this jar file graph
since the change of a one jar may completely change the dependency sub graph.
The workaround is very easy add all jar files into project classpath.
*** Issue 122650 has been marked as a duplicate of this issue. ***
*** Issue 128536 has been marked as a duplicate of this issue. ***
The suggested "easy" workaround is not acceptable as the library jar normally comes from a third party source and can
be updated/modified independently from the project. All jars added once to the project may not reflect the recent
updates thus requiring manual updates of the project's class path, which breaks the whole idea of external library.
This is not an enhancement but rather a regression as Java Editor in NB55 does NOT have this problem.
The classpath logic is the same from the time of NB 4.1 in j2seproject.
NetBeans is supposed to be a Java IDE and as such needs to expose the features in the JDK!
classpath definition via manifest is a JDK feature, and this feature has to work with NetBeans classpath mechanism.
*** Issue 175482 has been marked as a duplicate of this issue. ***
Tomas, what's the rationale for turning this into enhancement? It is a defect and I cannot find any argument which could
be used to justify it being enhancement. :-) If something works by executing javac on command line then the same
scenario should work in IDE as well otherwise it is defect, no? I can understand that it was introduced in J2SE5 but
that one has been around for a while now.
An example: glassfish server v3 comes with glassfish/lib/embedded/glassfish-embedded-shell.jar which links more then
dozen of internal glassfish JARs. You would not want to add these individual internal jars directly to project's
classpath so the workaround you suggested is impractical. This is not an issue in current Web/EJB project which handle
these jars differently, but what I want to say is that with more JARs like that in base NB distribution the more likely
people will hit the problem.
I am going to release a java SDK with uses shell jars that requires class-path attributes in jar manifest to work.
But since NetBeans does not support the java standard in this respect, I guess I have to write in the documentation that only Eclipse and other IDE's that impl. the full java standard works (not NetBeans).
P.S. I have the same problem with Glassfish V3 shell jars and Netbeans.
*** Bug 186057 has been marked as a duplicate of this bug. ***
Another use case where this problem manifests: I'm writing an editor hint which checks project classpath for EE unit tests. I did use
but this never succeeds because api.java.Classpath ignores Class-Path manifest. The outcome is that editor hint reports false problem and unit test can be executed without problems.
*** Bug 198660 has been marked as a duplicate of this bug. ***