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 66275 - Need ability to add Sources and Javadoc when creating Library Wrapper Module Projects
Summary: Need ability to add Sources and Javadoc when creating Library Wrapper Module ...
Alias: None
Product: apisupport
Classification: Unclassified
Component: Project (show other bugs)
Version: 5.x
Hardware: All All
: P2 blocker with 2 votes (vote)
Assignee: rmichalsky
Keywords: UI
Depends on: 44035
Blocks: 89629
  Show dependency tree
Reported: 2005-10-07 18:11 UTC by William Leonard
Modified: 2009-08-31 20:18 UTC (History)
3 users (show)

See Also:
Exception Reporter:


Note You need to log in before you can comment on or make changes to this bug.
Description William Leonard 2005-10-07 18:11:15 UTC
I'm working with the eBay SDK for Java (, which
provides its Javadoc in a folder (D:\eBaySDKforJava1.1.2\docs\LibRef). If I
create a library for the eBay SDK and configure it's Javadoc folder, the editor
will properly pick up the Javadoc from a J2SE project, but not from a module
project (it's not found).
Comment 1 Jesse Glick 2005-10-07 23:20:49 UTC
Cannot reproduce.

I downloaded and unzipped to "/tmp/eBay SDK for
Java 1.2.0". I made a new lib "ebay" with classpath consisting of the five JARs
in the "lib/" folder, and Javadoc consisting of the "docs/LibRef/" folder. I
made a j2seproject, added the ebay lib to it, and used ApiCall in a new class.
Code completion found Javadoc as expected.

Now I make a module suite. I add a lib wrapper to it with ebaysdkcore.jar. I
added the copied JAR (from release/modules/ext/) to the lib's classpath
definition so it will be associated with the Javadoc too. I add a new module to
the suite and add the ebay wrapper as a dep. I add a class to it and use
ApiCall. Code completion works again as expected.

[BTW when filing bugs please include at least as detailed steps to reproduce as
I provide above.]
Comment 2 William Leonard 2005-10-10 16:34:59 UTC
Ok, so the step I missed was adding the copied jar to the libary. This is an
ugly workaround. I'll change this to an enhancment request to be able to include
Javadoc when defining library wrapper modules. Certainly this would be of value.

Old Summary was: Module projects do not recognize Javadoc when configured as a
folder in the Library Manager

I'm now requesting that you can add Sources and Javadoc to Library Module
Wrapper projects as you can with standard Libraries.
Comment 3 Jesse Glick 2005-10-27 21:41:13 UTC
Probably WONTFIX in its current form, because there are independent plans to
make a position-independent library descriptor, but not for 5.0. Without that,
apisupport could only define its own special format, which is not a good idea I
Comment 4 Martin Krauskopf 2006-02-15 14:28:45 UTC
BTW, not sure why but the workaround does not (stops to) work. It is very hard
to develop agains the 3rd party library if you do not know its API details
(trunk, but probably 5.0u1 as well - did not try 5.0).
Comment 5 Martin Krauskopf 2006-02-24 11:49:36 UTC
Ignore my last comment. I did not use _exactly the same_ jar.
Comment 6 Jesse Glick 2007-04-11 22:03:49 UTC
Could be implemented using issue #44035, but it is unlikely I or anyone else
will have time to work on apisupport to do so.
Comment 7 Milos Kleint 2008-07-25 11:03:50 UTC
is this the only issue regarding the inability to see javadoc for binaries that are part of the module?
How am I supposed to code against 3rd party libaries in a platform based app?

sounds like a P2 bug, not an enhancement..
Comment 8 Jesse Glick 2008-07-25 14:25:29 UTC
As mentioned above, you can associate sources and Javadoc using a separate library for now.
Comment 9 Milos Kleint 2008-07-25 14:59:48 UTC
"for now" has been almost 3 years already :(

I've never felt the problem so far, but since migrating the maven modules to ant from maven, it's been rather painful to
make sense of any of the maven/nexus method calls.

please consider for the version. Preferably in the same way jar dependencies are handled in j2se projects.
Comment 10 Jesse Glick 2008-07-25 18:21:20 UTC
Well, migrating from Maven to Ant is going to be painful no matter what the IDE does because Maven would automatically
give you the sources for such JARs and Ant will not. apisupport.project does not even have a GUI for
<class-path-extension> yet; even if it did, at best you would be able to manually enter a path to sources which would be
stored in nbproject/private/ somewhere. A little easier than creating a library descriptor, but not much better.
Comment 11 Milos Kleint 2008-07-28 07:35:11 UTC
it should be at least on par with the j2se project type's support for jar's javadoc. While we don't have that many 3rd
party libs in netbeans IDE itself, I think it's quite common for other products based on the platform. 
Comment 12 Jesse Glick 2008-07-28 14:44:52 UTC
Correction: there is a Libraries node now, to which you could add an action like Set Javadoc. Could store location in (BTW we *really* need a common infrastructure for Libraries nodes.)
Comment 13 _ rkubacki 2009-06-22 19:35:53 UTC
Can someone reiterate our choices how to workaround this? Preferably with a links to a documentation. There should be a
way if this is only RFE.

I do not see how to fix it by editing <class-path-extension> (#desc11) neither I know how to make a sharable library
descriptor used by apisupport project. If I could put foo-src.jar next to my foo.jar and get sources association
(+javadoc) working I'd be happy.
Comment 14 rmichalsky 2009-06-23 15:50:38 UTC
I've just tried Jesse's workaround described in desc2 and it really works. The critical part is that you have to add
JARs from <lib wrapper>/release/modules/ext on Classpath in Library Manager for this to work. I admit that this really
doesn't fit into team environment.

As there is no work on "position-independent library descriptor" I know of, I'd just allow to put relative paths to
source & javadoc into of the lib wrapper + added some GUI to support it (e.g. on Sources tab in
Project properties). Sources & javadoc for external clusters are done in similar way, and it seems to work well. Any
Comment 15 Jesse Glick 2009-06-23 20:24:34 UTC
j2seproject etc. do support sharable libraries, e.g. lib/ I don't know much about the final API
for this (worked on an early version), so talk to the authors - dkonecny and mkleint IIRC.
Comment 16 rmichalsky 2009-06-24 13:24:39 UTC
Talked to Milos, I guess I got the basic idea. Sharable libraries are useful for libraries consisting of multiple JARs
and many projects using them, which is not a typical use case with lib wrappers - usually only the wrapper will
reference the library directly and our FAQ states that we don't generally recommend putting multiple JARs into single
wrapper (although it is useful at times).

On the other hand J2SE project also allows to add source&javadoc to single JAR the way I described above. So I guess I'd
implement this approach first and see if it suffices or there is demand for shared libraries.
Comment 17 rmichalsky 2009-08-27 14:07:27 UTC
Pushed in core-main #612151d66b5f.

There are two ways now, how to add src & javadoc:

1) Via UI added in issue #66188, go to project Properties -> Libraries -> Wrapped JARs -> Edit

2) Via convention over configuration: just put folder or ZIP named "<JAR name without ext.>-javadoc(.zip)" and/or "<jar
name without ext.>-src(.zip)" next to wrapped JAR and it will be picked up automatically (thanks Milos for the idea)
Comment 18 Jesse Glick 2009-08-27 15:53:41 UTC
Style #2 would generally be undesirable if the JAR were in the usual location of release/modules/ext, since you would
end up including src/javadoc in the final app.
Comment 19 Milos Kleint 2009-08-28 12:18:34 UTC
jglick: is it? why do we get so much configuration (1 or 2 properties in and 1 or 2 elements in
project.xml) then if everything gets copied anyway..
Comment 20 Jesse Glick 2009-08-28 14:09:45 UTC
mkleint - yes files in release/ are copied to ${cluster} (and registered in the NBM fileset) automatically; nothing else
is required (except <class-path-extension> in project.xml if you indeed wish to add items to Class-Path). See
harness/README. Perhaps you are thinking of release.* properties, which are primarily useful in sources since we
are required to keep third-party libraries in */external/ dirs. See DevFaqExternalLibraries.
Comment 21 Quality Engineering 2009-08-31 20:18:56 UTC
Integrated into 'main-golden', will be available in build *200908311509* on (upload may still be in progress)
User: Richard Michalsky <>
Log: #66275: src & javadoc for lib wrappers