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 15489 - Remove incidental classpath from Java process executor
Summary: Remove incidental classpath from Java process executor
Status: CLOSED FIXED
Alias: None
Product: java
Classification: Unclassified
Component: Unsupported (show other bugs)
Version: 3.x
Hardware: PC Linux
: P3 blocker (vote)
Assignee: issues@java
URL:
Keywords:
: 11695 (view as bug list)
Depends on:
Blocks: 22914
  Show dependency tree
 
Reported: 2001-09-13 23:10 UTC by Jesse Glick
Modified: 2007-09-26 09:14 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:

Attachments
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 Jesse Glick 2001-09-13 23:10:42 UTC 
[dev sep 10] Java external (process) executors still have a classpath
containing the IDE's own classpath and library path. This is
inconsistent with compiler types which by default use only the
user-supplied Filesystems.
Comment 1 Svata Dedic 2001-09-19 09:41:58 UTC 
Milestone changed -- the behaviour won't be changed for 3.3
Comment 2 Svata Dedic 2002-03-26 17:37:41 UTC 
Adjusting milestone -- 4.0 is really far away yet.
Comment 3 Svata Dedic 2002-04-04 12:27:23 UTC 
x
Comment 4 Svata Dedic 2002-04-15 09:58:53 UTC 
CC:ing documentation team members
Comment 6 Svata Dedic 2002-05-21 13:46:17 UTC 
*** Issue 11695 has been marked as a duplicate of this issue. ***
Comment 7 Patrick Keegan 2002-07-29 23:02:49 UTC 
Jesse, what do you think is the best way to note this for the release? 
Shouldn't it appear somewhere in the changes document?
Comment 8 John Jullion-ceccarelli 2002-07-30 10:04:27 UTC 
I've documented this directly in the help, changing each mention of the internal IDE classpath including 
"mounted filesystems and various directories in your IDE installation directory" to just say it includes 
"all mounted filesystems". Do we need a release note as well? I think Svata's doc mostly concerned 
documenting this in the APIs so module writers know about the change.
Comment 9 Jesse Glick 2002-07-30 15:18:02 UTC 
Hmm, the Upgrade Guide already contains a mention of this stuff, but I
can link to Svata's documents as well. Stuff for module authors
belongs in the upgrade guide, not really the release notes I guess.

SVATA - your links are broken, I cannot find such docs.

HOWEVER Patrick it would be a really good idea for the release notes
to mention the existence of the Upgrade Guide as part of the Open APIs
documentation set, and refer module authors to it for all interesting
API-related changes.
Comment 10 Patrick Keegan 2002-07-30 16:34:20 UTC 
OK. I'll add a reference to the upgrade guide in the docs. Should it 
be the whole thing or just the 3.3 -> 3.4 part?

Removing RELNOTE keyword since seems to be a change end users won't 
really notice. Respond if you disagree.
Comment 11 Jesse Glick 2002-07-30 17:15:50 UTC 
Just link to the complete upgrade guide notes (I sent Patrick a good
link to use).

Re. adding this to release notes: need opinion from Java module
developers, because it depends how user project compatibility was
maintained (or not maintained). If an existing project from 3.3 was
set up to rely on executors including NB libraries in the classpath,
what will happen in 3.4? Is the executor automatically converted to
include these libs in an explicit classpath? Or will the default
executor no longer include them, so the user needs to readd them if
they were really desired?
Comment 12 Jan Becicka 2003-02-28 14:18:36 UTC 
Verified
Comment 13 Quality Engineering 2003-07-01 13:18:44 UTC 
Resolved for 3.4.x or earlier, no new info since then -> closing.