| Summary: | [javadoc export] Generate javadoc selected archives behave erratically | ||
|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Reuben Sivan <reuben.sivan> |
| Component: | UI | Assignee: | JDT-UI-Inbox <jdt-ui-inbox> |
| Status: | CLOSED WONTFIX | QA Contact: | |
| Severity: | minor | ||
| Priority: | P3 | ||
| Version: | 3.1.2 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | stalebug | ||
|
Description
Reuben Sivan
In addition to the above, some of the javadoc locations configured in the dialog for referred jars get erased at every new application. The selected elements are always derived from your current selection. That's the design. To rerun a Javadoc generation, save the export as ANT file (last page) and rerun the ANT file. (In reply to comment #2) > The selected elements are always derived from your current selection. That's > the design. > To rerun a Javadoc generation, save the export as ANT file (last page) and > rerun the ANT file. > It is not a bad suggestion to use an ANT file, but it is quite unexpected that the selected jars are not remembered between runs. Looks like a bug to me, although clearly a minor one. All wizards initialize the values from the actual selection, so we want to be consistent here. Certainly a bug, behavior is NOT consistent with other wizzards. There is no wizzard in which the checkmarks get changed erratically and settings are not remember across uses. I am now using 3.1.2 and still finding the same bahavior. To recup: Seelct project-generate javadoc while a project is selected in the package explorer pane. The part of the dialog showing 'Select referenced archives and projects..." is initialized with a check on dnsns.jar, - not configured, junit.jar - not configured, localedata.jar, rt.jar - not configured, sunjecr, sunpkcs11.jar, many of those are not used at all in my project. Press clear all, then select only rt.jar. WHile selecting rt.jar select browse and configure the location of the javadoc. (this was already configured in the project, but this dialog is ignoring that configuration). Press OK after you selected the location and validated it. rt.jar is no longer checked; the rt.jar javadoc configuration shows ok. Check rt.jar, press finish. When your javadoc completes, start again: Project, generate javadoc. At the dialog press next. The list of jars has nothing selected this time. rt.jar again shows not-configured. It is a bug that configuring the javadoc location rt.jat gets lost. That's fixed in 3.2. But the libraries available in this dialog depending on the initial selection. Each project has different libraries on the classpath you can reference, so it's not a simple remembering of checked states. Please name me the wizard which remembers such settings. (In reply to comment #6) > It is a bug that configuring the javadoc location rt.jat gets lost. That's > fixed in 3.2. > But the libraries available in this dialog depending on the initial selection. > Each project has different libraries on the classpath you can reference, so > it's not a simple remembering of checked states. Please name me the wizard > which remembers such settings. > I just went through the process again, to confirm the steps: Create javadoc, first time, no checkmarks on any library, even though some of the libraries are in use. Configured rt.jar, set a checkmark on it and on a jakarta library that was properly configured. Later I generated javadoc again. This time junit.jar has a checkmark, the jakarta and rt.jar do not have one. This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie. |