Bug 105927 - Projects ignore class-path attribute in jar manifest
Projects ignore class-path attribute in jar manifest
Status: NEW
Product: java
Classification: Unclassified
Component: Project
6.x
Sun All
: P2 with 1 vote (vote)
: 6.x
Assigned To: Tomas Zezula
issues@java
:
: 105928 122650 128536 175482 186057 198660 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2007-06-06 19:44 UTC by _ ludo
Modified: 2011-05-17 15:08 UTC (History)
4 users (show)

See Also:
Issue Type: ENHANCEMENT
:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description _ ludo 2007-06-06 19:44:13 UTC
Latest nb 6 build.
Create a java project, and in the "Libraries" node, add a jar that contains an
entry like

Class-Path: foo.jar 

where foo.jar is in the same directory of this jar.

If foo.jar defines the class com.acme.Foo

try to add
import com.acme.Foo;
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.
Comment 1 _ ludo 2007-06-06 19:46:00 UTC
same for web app projects...
Comment 2 _ ludo 2007-06-06 19:46:08 UTC
same for web app projects...
Comment 3 _ ludo 2007-06-06 20:50:16 UTC
*** Issue 105928 has been marked as a duplicate of this issue. ***
Comment 4 _ ludo 2007-06-06 20:50:20 UTC
*** Issue 105928 has been marked as a duplicate of this issue. ***
Comment 5 Tomas Zezula 2007-06-07 08:39:23 UTC
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.
Comment 6 Tomas Zezula 2007-11-26 16:13:23 UTC
*** Issue 122650 has been marked as a duplicate of this issue. ***
Comment 7 Jan Lahoda 2008-02-27 12:25:25 UTC
*** Issue 128536 has been marked as a duplicate of this issue. ***
Comment 8 ayermolayev 2008-02-27 12:38:05 UTC
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.
Comment 9 ayermolayev 2008-02-27 12:42:48 UTC
This is not an enhancement but rather a regression as Java Editor in NB55 does NOT have this problem.
Comment 10 Tomas Zezula 2008-02-27 14:07:01 UTC
The classpath logic is the same from the time of NB 4.1 in j2seproject.
No regression.

Comment 11 _ ludo 2008-10-02 04:15:47 UTC
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.

Comment 12 Vitezslav Stejskal 2009-10-27 13:18:55 UTC
*** Issue 175482 has been marked as a duplicate of this issue. ***
Comment 13 David Konecny 2009-10-27 22:18:11 UTC
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.
Comment 14 mortench 2010-04-08 08:49:39 UTC
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.
Comment 15 Dusan Balek 2010-05-18 12:25:46 UTC
*** Bug 186057 has been marked as a duplicate of this bug. ***
Comment 16 David Konecny 2011-02-20 22:55:23 UTC
Another use case where this problem manifests: I'm writing an editor hint which checks project classpath for EE unit tests. I did use

  anExecutionClasspath.getClassLoader(true).loadClass(aClassToTest)

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.
Comment 17 Dusan Balek 2011-05-17 09:41:20 UTC
*** Bug 198660 has been marked as a duplicate of this bug. ***


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo