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 9637 - In multi-user mode, Forte searches for classes that are not present in the users directory.
Summary: In multi-user mode, Forte searches for classes that are not present in the us...
Status: CLOSED INVALID
Alias: None
Product: platform
Classification: Unclassified
Component: -- Other -- (show other bugs)
Version: 3.x
Hardware: All Other
: P1 blocker (vote)
Assignee: _ ttran
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2001-02-15 16:03 UTC by Martin Grebac
Modified: 2008-12-23 10:49 UTC (History)
3 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:

Attachments
ide.log with exceptions (21.00 KB, text/plain)
2001-07-20 20:30 UTC, Martin Grebac 		Details
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Martin Grebac 2001-02-15 16:03:06 UTC 
In multiuser mode, while starting, Forte searches for classes in
USERDIR/modules/ext package, but these classes are located in
FORTE/modules/ext.

 Steps to reproduce:
  1. Install FFJ 2.0 IE
  2. Run the IDE in multiuser mode
  3. Use autoupdate for updating module JSP (r.n. 26786643)

 What happens after:
  IDE automaticaly restarts, but does not finish the restart, just throws
exceptions while trying to locate classes in the ext/xmlview.jar package in the
user's directory.
Comment 1 Martin Grebac 2001-02-15 16:07:59 UTC 
Created attachment 628 [details]
ide.log with exceptions
Comment 2 _ ttran 2001-02-15 22:45:19 UTC 
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
Comment 3 Antonin Nebuzelsky 2001-02-16 10:05:10 UTC 
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.
Comment 4 Jesse Glick 2001-02-16 13:39:39 UTC 
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.
Comment 5 _ ttran 2001-03-13 13:03:28 UTC 
see Jesse's comment
Comment 6 Quality Engineering 2003-07-01 15:47:45 UTC 
Resolved for 3.4.x or earlier, no new info since then -> verified.
Comment 7 Quality Engineering 2003-07-01 16:13:39 UTC 
Resolved for 3.4.x or earlier, no new info since then -> closing.