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 180707 - Java Class Library Project always contains Class-Path in Manifest
Summary: Java Class Library Project always contains Class-Path in Manifest
Status: RESOLVED FIXED
Alias: None
Product: java
Classification: Unclassified
Component: Project (show other bugs)
Version: 6.x
Hardware: All Windows Vista
: P2 normal with 1 vote (vote)
Assignee: Tomas Zezula
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-02-14 22:53 UTC by bht
Modified: 2010-02-24 08:40 UTC (History)
4 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments
testcase (zip file) (46.04 KB, application/zip)
2010-02-15 00:16 UTC, bht
Details
Screen shot as proposal (10.22 KB, image/gif)
2010-02-16 14:23 UTC, bht
Details

Note You need to log in before you can comment on or make changes to this bug.
Description bht 2010-02-14 22:53:42 UTC
How to reproduce:

- File|New Project|Java|Java Class Library|Finish
- In Projects View, on the Libraries node, right click and select "Add Library", choose one and click "Add Library"
- On the project node, click "Build"
- Go to the Files View, open the jar node in the dist folder, then folder META_INF.
- Open file MANIFEST.MF

There is an entry Class-Path: lib/<list of jar files contained in the selected library>

- Deploy that jar file with a GlassFish V3 project (no problem with GlassFish V2)

The problem with this is that if such a jar file is read by GlassFish V3, it fills up the log file with messages:

WARNING: PWC6351: In TLD scanning, the supplied resource file:/<pathelement>/dist/gfdeploy/<pathelement>/lib/lib/whatever.jar does not exist
java.io.FileNotFoundException: ...

Please note the path element "/lib/lib" which does not exist.

Filling up the log file is a very big problem because NetBeans will completely freeze with 100% CPU utilization and OutOfMemoryError due to another bug that exists (I remember having seen it but I can't find it, please tell me if you know) between the IDE and GlassFish.

If as a moderately skilled developer one just quickly creates or worse inherits a library and deploys it in GlassFish then one is suddenly faced with a very complex set of problems that are very hard to diagnose.

In this case, it took more than a day to trace the GlassFish 100%-CPU / out-of-memory errors back to this. The extreme difficulty is in identifying the source of the offending classpath entry especially if the entries are used elsewhere in the project (most likely).

Is there a way to turn this entry off quickly?
Comment 1 bht 2010-02-15 00:16:09 UTC
Created attachment 94150 [details]
testcase (zip file)

The testcase contains 4 projects that need to be built, and a server log file showing the warnings.
Comment 2 Tomas Zezula 2010-02-16 06:27:29 UTC
You can turn off the Class-Path attribute in manifest by adding following line into project.properties:
mkdist.disabled=true
Comment 3 Tomas Zezula 2010-02-16 06:33:40 UTC
Unfortunately this behavior was requested for j2se projects (libraries). 
If I change it I will get another P2 from the original reporter requiring this feature.
I can try to add the Class-Path attr only if there is a main class. But users will complain about it.
David what do you think about it?
Comment 4 bht 2010-02-16 14:23:44 UTC
Created attachment 94209 [details]
Screen shot as proposal

Thanks very much for the workaround. Much appreciated!

I don't have an opinion on whether or how to change the current IDE behavior.
A possible solution would be to change the libraries panel to include an option check box for every entry marking it for inclusion in the Class-Path list, and if no entries have this selected then do not include the Class-Path entry at all.

Please refer to attached screen shot from an ejb project (in that, the check box is called "Package").
Comment 5 bht 2010-02-16 14:41:33 UTC
For a Class Library project, Class-Path ./lib in most cases resolves to ./lib/lib which again in most cases does not exist. To get this right, the path would have to be editable. May be a check box to enable Class-Path generation and a text field for the path with default "lib"?
Comment 6 Tomas Zezula 2010-02-17 02:24:04 UTC
Reassigning to David for evaluation as it's related to the glassfish integration.
Comment 7 David Konecny 2010-02-17 19:00:52 UTC
Re. "behavior was requested for j2se projects" - I don't think this should ever be a default behaviour. Having a checkbox in project properties whether to generate ClassPath attribute in manifest or not which would be by default set to true for J2SE application and false for everything else would be better. At least for J2SE library project it does not make much sense no? Classpath to run library in should be defined by application which is going to use the library.

On GF side only warning text should be reported and not whole exception stack trace in default log level. That is slightly excessive. Would you agree Vince?
Comment 8 Petr Jiricka 2010-02-18 03:12:16 UTC
One other question - when NB is adding the Class-Path attribute, why does it assume that the library it refers to will be located in the "lib" subdirectory at runtime? Is it really typical that libraries used by your library will be in a separate subdirectory? I think "lib" is not the best default, why not just put all the jar files in the same directory, without any subdirectories? 

See also the scenario in bug 180886 that I just filed.
Comment 9 Tomas Zezula 2010-02-18 05:56:06 UTC
pjiricka: See my comments in issue #180886
Comment 10 David Konecny 2010-02-18 12:57:48 UTC
Looking at bug 180886 the ClassPath attribute generation makes sense only in J2SE Application Project or any project which acts as top level application project with main class to start the project. That would resolve this issue and 180886.
Comment 11 Tomas Zezula 2010-02-18 13:39:59 UTC
Yes, I will change it in a way that Class-Path is added and library copied only in case the main.class is set.
Comment 12 Tomas Zezula 2010-02-24 08:40:13 UTC
Fixed in jet-main: 03c53d647a60