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.
Create javaapi module that will allow other Java-based modules to communicate between each other and do not realy on services provided by OpenAPIs, especially abstract from the actual CLASSPATH construction.
Target milestone should be the next version of NetBeans as explained at http://www.netbeans.org/servlets/ReadMsg?msgId=182132&listName=nbdev
We (debugger - Add Breakpoint Dialog) need some way how to immediately find Java Element currently selected in Java editor. Out current procedure: n[] = SomeAction.getActivatedNodes (); Element e = (Element) n [0].getCookie (Element.class); .. does not return current state. There is some delay (1000ms).
I've tried to create initial version of the API on java_api_2001 branch. Please check out: http://www.netbeans.org/source/browse/java/src/org/netbeans/api/java/Attic/JavaEnvironment.java
I have at least some initial comments :-) 1. the interface assumes immutability of the information (no change notification) 2. there's not only a single classpath; examples exist that multiple class/resource paths are needed for compile-time and runtime (and maybe as well for debug-time). But that can be also coded as multiple environments (distinguished by some attribute). 3. If I undestand it correctly, then find(do) will be used only as a compatibility call after new project impl comes to life and new find () call (parametrized with project context) will appear. Is that correct ?
Ad1: Right. I do not understand all requirements - will be added later. Ad2: getClassPath () was intended just for execution & debugging (I assumed that those are same). For additional sources (of JDK for example) I planned to use the find method that can search more than just the classpath. But maybe the getLibrary method is missing!? Ad3: I hoped that find (do) expresses the context enough - expecting list of projects sorted by importance, with list of groups sorted by importance and that for practical reasons one DO can be in one project at a time only.
Guys, what is your feeling about the proposal? If you generally agree could we continue to change the structure of java&clazz modules to create some java-api.jar autoload module in main trunk?
CCing people who should review the proposal.
Milestone 4 is ok for final implemenation date, but I expect wide discussion before it. Should not most of the problems be figured out before say milestone 2? Should not we have subissue ensuring that it will happen?
Yardo, I agree. I have filed subtask 21537 scheduled for milestone 3. We will try to make it available even sooner, but I cannot commit to have it in milestone 2.
Martin R., I think you had a proposal for a "profile" management system at one point that would permit not just classpath but also boot classpath, parser DB, etc. to be configured atomically for all compilers, executors, debuggers, and so on - is this proposal still alive somewhere?
There was a rough proposal (http://java.netbeans.org/Proposals/Profiles/profiles.html) that summarizes requirements for such profile management. However, the proposal was created year ago and I'm not sure whether it is still up to date. Some of the ideas described here are implemented in FFJ 4.0 ME.
Fixed -- the API was merged into dev trunk, build scripts were updated.
Adjusting milestone for planning
Svata what you are doing? This task is part of work targeted for 3.4 and is fixed!? I expect that you did the change by mistake, so I reverted it to 3.4 and marked it verified.