Bugzilla – Full Text Bug Listing
| Summary: | Javadoc missing from IRuntimeClasspathEntry entries | ||
|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Martin Aeschlimann <martinae> |
| Component: | Debug | Assignee: | Kevin Barnes <cocoakevin> |
| Status: | VERIFIED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P2 | CC: | bradley.wagner |
| Version: | 3.1 | ||
| Target Milestone: | 3.2 RC1 | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | |||
|
Description
Martin Aeschlimann
The runtime classpath entries (IRuntimeClasspathEntry) only store equivalent classpath entries (IClasspathEntry) in terms of the location they point to for .class files. The rest of the attributes/rules, etc., are not included in the classpath entries. Looking at our use of the IClasspathEntry for an IRuntimeClasspathEntry, it appears we only use it to allow re-use of the JUI source attachment dialogs (which talk in terms of IClasspathEntry). Not sure what we should do about this. Aren't the entries normally created from entries acquired with getRawClasspath? It would be nice if you can just copy all the extra attributes there as well. One of the ideas of extra attributes is that users might add them. One of the motivations could be to do something with them when launching (e.g. similar to what the native library attibute does). They may be initially created from the runtime classpath, but users can add additional entries, and we persist/restore them ourselves. Thus, we don't persist extra attributes. It's no problem it the user added entries won't have a javadoc location added. In my case of the Javadoc wizard, the lauchconfig is always created right away, persisting is not important here. So a quick solution would be to keep the extra attributes when creating the entries from classpath entries, but don't persist them. However I think the right thing to do is to also persist them. As said, users might want to store launch relevant information in the extra attributes. The other issue is updating a runtime classpath entry. Currently, if you change the source attachement, etc., on a runtime classpath entry, the change is not propogated to the associated buildpath entry. There are two reasons for this: 1) there may be no associated buildpath entry (users can add extra runtime entries) 2) the user may want to have a different runtime classpath than buildtime classpath This is just to say that making changes to the runtime classpath will not be reflected in the buildpath. Will investigate maintaining/initializing attributes on runtime entries when created form/with a project context. Will not persist. Moving to M4. *** Bug 129498 has been marked as a duplicate of this bug. *** Martin, the javadoc attributes are on the entries in a container, not the container itself. I might be able to add the entries to the "entries" in the container, but I'm not sure you are using them? Yes, on the entries inside of the container. To see how we use it, look at JavadocStandardWizardPage.collectReferencedElements (line 295). A JavadocLinkRef then gets the javadoc location from the IClasspathEntry. Fixed in JRERuntimeClasspathEntryResolver and RuntimeClasspathEntry. The javadoc locations are now propogated to the underlying IClasspathEntry in the IRuntimeClasspathEntry. verified |