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: | In multi-user mode, Forte searches for classes that are not present in the users directory. | ||
---|---|---|---|
Product: | platform | Reporter: | Martin Grebac <mgrebac> |
Component: | -- Other -- | Assignee: | _ ttran <ttran> |
Status: | CLOSED INVALID | ||
Severity: | blocker | CC: | anebuzelsky, issues, ppisl |
Priority: | P1 | ||
Version: | 3.x | ||
Hardware: | All | ||
OS: | Other | ||
Issue Type: | DEFECT | Exception Reporter: | |
Attachments: | ide.log with exceptions |
Description
Martin Grebac
2001-02-15 16:03:06 UTC
Created attachment 628 [details]
ide.log with exceptions
modules/ext is not the launcher's business, this bug cannot be mine. A wild guess: module abc declares in its manifest using Class-Path that it wants ext/xmlview.jar. Auto-update updated (added) xmlview.jar in {ide.user}/modules/ext, the old {ide.home}/modules/abc.jar is still used. Class-Path: ext/xmlview.jar means a relative path to abc.jar. We need to update also abc.jar so that it will be put in {ide.user}/modules This is exactly the point! Why should we distribute a jar that didn't change a bit. I think the launcher should be able to replace {ide.user}/modules/ext/some.jar by {ide.home}/modules/ext/some.jar on classpath if there is no some.jar in {ide.user}/modules/ext. I vote to mark this WONTFIX. The NBM should include the module and its extensions. What if the user's didn't have JSP installed to begin with?? It is the fault of the person who packaged this NBM the way they did. If there is some way in the NBM syntax to declare that you are patching *part* of a module's installation (e.g. just docs, just an extension, just main module, just localized variants, just parser database) then the IDE should deal with it. But AFAIK there is no such protocol, an NBM is assumed to be complete. It would not be difficult to modify the core to search for extensions the way you describe (in the trunk at least, in boston probably more difficult), but I am not convinced this is desirable. Extensions tend to be tightly tied to the module's implementation, strictly adhering to the Extension Specification's definition of where they should be found is probably best. see Jesse's comment Resolved for 3.4.x or earlier, no new info since then -> verified. Resolved for 3.4.x or earlier, no new info since then -> closing. |