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.
Summary: | Java Class Library Project always contains Class-Path in Manifest | ||
---|---|---|---|
Product: | java | Reporter: | bht <bht> |
Component: | Project | Assignee: | Tomas Zezula <tzezula> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | dkonecny, pjiricka, tzezula, vkraemer |
Priority: | P2 | ||
Version: | 6.x | ||
Hardware: | All | ||
OS: | Windows Vista | ||
Issue Type: | DEFECT | Exception Reporter: | |
Attachments: |
testcase (zip file)
Screen shot as proposal |
Description
bht
2010-02-14 22:53:42 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.
You can turn off the Class-Path attribute in manifest by adding following line into project.properties: mkdist.disabled=true 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? 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").
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"? Reassigning to David for evaluation as it's related to the glassfish integration. 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? 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. pjiricka: See my comments in issue #180886 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. Yes, I will change it in a way that Class-Path is added and library copied only in case the main.class is set. Fixed in jet-main: 03c53d647a60 |