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 167955 - Error marks in editor when a J2SE project depends on a module project which is wrapping external libraries
Summary: Error marks in editor when a J2SE project depends on a module project which i...
Status: REOPENED
Alias: None
Product: java
Classification: Unclassified
Component: Project (show other bugs)
Version: 6.x
Hardware: All All
: P3 blocker with 1 vote (vote)
Assignee: Tomas Zezula
URL:
Keywords:
: 167953 (view as bug list)
Depends on:
Blocks:
 
Reported: 2009-07-01 12:55 UTC by _ moser
Modified: 2011-08-31 14:08 UTC (History)
1 user (show)

See Also:
Issue Type: ENHANCEMENT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description _ moser 2009-07-01 12:55:06 UTC
I have a module suite with a lot of library wrapper modules. I also have some J2SE projects for
which I have defined project dependencies to some of the library wrapper modules.

I can build these Java projects (within the IDE as well as from the command line) - that's fine so far. But when editing
files of a Java project which depends on classes from a library wrapper project, the IDE marks all references to the
library classes as errors (and as a consequence does not offer code completion etc.) until I add explicit dependencies
to the jars from the "release/modules/ext" folder of the wrapper projects.

I suppose this to be a bug or am I missing some configuration trick?

If this is intended behaviour, this issue should be changed into an RFE to autmatically add these external libraries
when a dependency to such a module is added to a J2SE project.

Frank-Michael
Comment 1 Peter Pis 2009-09-10 15:32:55 UTC
*** Issue 167953 has been marked as a duplicate of this issue. ***
Comment 2 Jan Jancura 2009-09-18 12:52:29 UTC

*** This issue has been marked as a duplicate of 59357 ***
Comment 3 _ moser 2009-09-18 14:48:39 UTC
I reject this issue being a duplicate of 59357 and I reject this issue being resolved. This issue is not about
transitive module dependencies but on direct dependencies to a wrapped library. For 59357  it is true that the classes
of module C only should be in the runtime classpath but not in the compile-time classpath. For a library wrapper this is
not true: it wraps an external libray to allow another module direct compile time dependencies and so it MUST add the
wrapped library to the compiletime classpath (if at least a single packege from the wrapped library is declared as
public packe)).
Comment 4 Jan Jancura 2009-09-21 12:58:18 UTC
Standard NetBeans distribution does not contain anything like Java Library Wrapper Project.
We have Java Class Library project type. But this project type is not designed for wrapping of some other "jars". Its
designed for developing your own libraries (your code in src dir).
So, you have to add dependencies form your J2SE projects to all library jars. Creating Java Class Library projects is
useless in your case.


*** This issue has been marked as a duplicate of 59357 ***
Comment 5 _ moser 2009-09-21 13:26:22 UTC
Of course Standard NetBeans comes with a Library Wrapper Module project type:
File/NewProject/NetBeansModules/LibraryWrapperModule. W.r.t. this, all previously said holds and I must continue to
reject this issue being resolved (as well as rejecting being a duplicate of the other cited issue).
Comment 6 Jan Jancura 2009-09-21 13:54:12 UTC
Ups, so you have "Java Application" project that depends on "NetBeans Modules/Library Wrapper Module"? That is
definitely not supported! There is no guarantee what will happen in this case!
Comment 7 _ moser 2009-09-21 14:00:07 UTC
Cant believe, it is even supported by the UI: "Add Project" in the dependendies section of the properties dialog allows
to add module projects as dependencies to J2SE project. And this with good reason, it has high value for for all those
developers writing lots of platform modules. Every other aspect of this kind of dependency works fine. Where does you
"definitely not supported" comes from? And why not takeing this at least as valid RFE!