Please use the Apache issue tracking system for new NetBeans issues (https://issues.apache.org/jira/projects/NETBEANS0/issues) !!
Bug 29914 - Separate Debugger API from openide-deprecated.jar
Separate Debugger API from openide-deprecated.jar
Status: RESOLVED FIXED
Product: platform
Classification: Unclassified
Component: -- Other --
3.x
All All
: P2 (vote)
: TBD
Assigned To: Jesse Glick
issues@platform
: API
Depends on: 30161
Blocks: 19443
  Show dependency treegraph
 
Reported: 2003-01-09 20:05 UTC by Jesse Glick
Modified: 2008-12-23 12:53 UTC (History)
8 users (show)

See Also:
Issue Type: TASK
:


Attachments
Working patch (not including S1S build script updates) (395.30 KB, patch)
2003-01-27 20:45 UTC, Jesse Glick
Details | Diff
Commit log (204.77 KB, text/plain)
2003-01-27 22:06 UTC, Jesse Glick
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jesse Glick 2003-01-09 20:05:18 UTC
It seems there is no ready replacement for the old
Debugger API and debugger clients still need to
use the old one. Possibly this will still be true
when the next NB or S1S release is made.

Therefore the Debugger API needs to be split out
of openide-deprecated.jar into a new module
modules/autoload/openide-debugger.jar,
openide/debugger/ in CVS. Should contain all
debugger-related classes: org.openide.debugger.*,
various things in org.openide.actions.*,
DebuggerCookie, ExecSupport (which now only adds
DebuggerCookie support to ExecutionSupport), maybe
also some beaninfos.

Clients of openide-debugger.jar should normally
require the token org.openide.debugger.Debugger.
debuggerCore.jar should provide it.

Old modules - pre-3.14, I guess - should depend on
org.openide.debugger > 1.0 and
org.openide.debugger.Debugger automatically. Ditto
newer modules which depended on a previous version
of org.openide.deprecated. This will make the
change fully compatible. Known modules should
however be updated to explicitly depend on
org.openide.debugger or not.

Debugger developers, does all this sound right?
Comment 1 Jesse Glick 2003-01-09 20:06:36 UTC
Of course Debugger API documentation should be restored and built with
this module, too.

Note that openide-debugger.jar would not be marked deprecated for now.
Therefore modules could use the old Debugger API without any
deprecation warnings, if they cleaned up uses of TopManager etc.
Comment 2 Jan Jancura 2003-01-13 09:33:02 UTC
I have some new API in projects branch, but I probably will not
backport it to trunk. So, I agree with your suggestion.
Comment 3 Jesse Glick 2003-01-13 15:55:43 UTC
OK, I will try to work on this soon. Hopefully can implement this week.

QA folks - you asked for advance notice in case of reorgs of
core/openide code. This would be one; however I don't think any
testing tools use the Debugger API in any way, so I doubt there would
be any structural impact. Probably just Martin Brehovsky need stay on
the CC list.
Comment 4 Martin Brehovsky 2003-01-13 16:08:16 UTC
OK thanks Jesse, it's good to be informed about major changes/reorgs,
even though they should not have any impact on our tools (you're
correct with usage of Debugger API - there is none from QA test tools
AFAIK).
Comment 5 Jesse Glick 2003-01-13 19:32:04 UTC
Creating branch:

cvs -d $CVSROOTHACK rtag debugger_api_29914_base core_nowww_1
openide_nowww_1 nbbuild_nowww_1 apisupport_nowww_1 applet_nowww_1
debuggercore_nowww_1 debuggerjpda_nowww_1 editor_nowww_1
j2eeserver_nowww_1 java_nowww_1 projects_nowww_1 rmi_nowww_1 web_nowww_1
cvs -d $CVSROOTHACK rtag -b -r debugger_api_29914_base
debugger_api_29914 core_nowww_1 openide_nowww_1 nbbuild_nowww_1
apisupport_nowww_1 applet_nowww_1 debuggercore_nowww_1
debuggerjpda_nowww_1 editor_nowww_1 j2eeserver_nowww_1 java_nowww_1
projects_nowww_1 rmi_nowww_1 web_nowww_1

Will not touch modules outside NB distro (incl. S1S); it will be their
responsibility to declare the proper new dependencies if they choose
to request a newer API version.
Comment 6 Jesse Glick 2003-01-13 21:51:04 UTC
Will make debuggercore/oldapi as the module, to get it out of openide
and make it more convenient for debugger developers to work on it.
(Compare org.openide.src -> java/srcmodel)

Re. uses of Debugger API org.openide.actions: I will leave them all in
openide-deprecated.jar. The only actions still used from openide are
AddWatchAction and ToggleBreakpointAction. I think these can be copied
into debuggercore and omitted from openide-debugger.jar:

- editor uses them in its popup menu by name; could come from system
class loader, no need to really be in openide

- editor gets TBA for gutter context menu; same

- JavaEditor.componentActivated sets TBA.actionPerformer; this could
be better done with Peter Z.'s new action context; ditto JspEditor
Comment 7 Jesse Glick 2003-01-21 02:47:12 UTC
Adding to the set of branched modules:

clazz
form
ant
jarpackager
tomcatint
Comment 8 Jesse Glick 2003-01-21 03:43:55 UTC
stable-with-apisupport moduleconfig now seems to build OK and run as
before.
Comment 9 Jesse Glick 2003-01-21 18:11:02 UTC
All standard unit tests pass as well.

QA folks (Martin Br.?), you may want to check that functional tests
are running normally in the branch. Or if you tell me what to look for
I can check it.

Editor & web developers: I made some nontrivial code changes to these
modules in the branch, mainly to avoid the need to have any
debugger-related action classes be public. Debugger developers:
obviously there were some changes related to the separation in
debuggercore as well. Please check the diffs if you have not done so
already:

cvs di -r debugger_api_29914_base -r debugger_api_29914
Comment 10 Jesse Glick 2003-01-27 20:07:41 UTC
All QA validation tests pass when the branch is merged with trunk code.
Comment 11 Jesse Glick 2003-01-27 20:45:19 UTC
Created attachment 8688 [details]
Working patch (not including S1S build script updates)
Comment 12 Jesse Glick 2003-01-27 22:06:59 UTC
Created attachment 8689 [details]
Commit log
Comment 13 Jesse Glick 2003-01-27 22:07:37 UTC
Done in trunk.


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo