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 257778

Summary:	remove dependency for editor.guards
Product:	editor	Reporter:	gwaldon <gwaldon>
Component:	-- Other --	Assignee:	Svata Dedic <sdedic>
Status:	NEW ---
Severity:	normal	CC:	sdedic
Priority:	P3
Version:	8.1
Hardware:	PC
OS:	Windows 7
Issue Type:	DEFECT	Exception Reporter:

Description gwaldon 2016-01-31 00:38:30 UTC

Not a bug nor an enhancement request but a will to keep the editor modular so that implementing the editor or part of it requires minimum modifications of netbeans code.

In NB8.1, org.netbeans.modules.editor.lib.DocumentGuardsImpl in editor.lib module and org.netbeans.modules.editor.impl.NbGuardedMarker in editor module appear and create a dependency on the editor.guards module.

Could send those two in the editor.guard module and not create a dependency? Tx.

Comment 1 gwaldon 2016-01-31 00:40:11 UTC

Implementing the editor within the platform I mean.

Comment 2 Svata Dedic 2016-08-10 07:09:17 UTC

The editor.guards module just provides an API + abstract layer for guarded block management. The implementation of the actual storage and document bindings is left to the Document implementor, that is editor.lib module in this case.

What's are the issues caused by the dependency when (re)implementing the editor ?

Comment 3 gwaldon 2016-08-10 16:50:19 UTC

It forces either to add the editor.guard module or manually edit the editor  module to have it not included in a custom editor implementation. The idea is to keep continuing having the editor very modular.

Comment 4 Svata Dedic 2016-08-11 06:58:57 UTC

I am still not entirely sure how removing a public API, and having clients to e.g. again depend on GuardedDocument implementation class would make editor.lib more modular. If the API stays there and is implemented by classes in editor.lib (by GuardedDocument), it's natural that editor modules depend on (implemented) API.

Without at least some API in editor.guards, clients had been forced to depend on editor.lib with all its swing and UI dependencies although the client has no UI at all.

Please elaborate why including classes for (already implemented) API is an issue. 

For example GuardedException is another candidate for move to editor.guards module and that one is used/detected by editor actions (again, exception resulting from modification attempt of a protected region is a non-UI concept, should not reside in editor.lib). I need a more solid understanding of other editor impl needs to make the separation smooth and usable, sorry.

Comment 5 gwaldon 2016-08-11 15:47:25 UTC

ok, let's keep things simple and maybe I missed something.

From NB8.0 to NB8.1 we found that when implementing our editor we now need a dependency on the editor.guard module. The dependency is due to an implementation class DocumentGuardsImpl in the editor.lib module which is not in a public package.

The question then is why not have this class in org.netbeans.modules.editor.guards which appears to be the implementation package of org.netbeans.api.editor.guards in the editor.guards module.

If this does not make sense or is not feasible because of possible cyclic dependencies between modules or anything else, let's close this. Otherwise let's move the class and not add unnecessary dependencies in NetBeans editor.