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 51486 - Split of the editor module into multiple modules
Summary: Split of the editor module into multiple modules
Alias: None
Product: editor
Classification: Unclassified
Component: -- Other -- (show other bugs)
Version: 4.x
Hardware: All All
: P1 blocker with 1 vote (vote)
Assignee: issues@editor
: 27138 (view as bug list)
Depends on:
Reported: 2004-11-13 11:17 UTC by Miloslav Metelka
Modified: 2007-11-05 13:44 UTC (History)
3 users (show)

See Also:
Issue Type: TASK
Exception Reporter:

Commit log from committing to the editor_split branch (136.10 KB, text/plain)
2005-01-10 18:15 UTC, Miloslav Metelka
Commit log from trunk integration (116.77 KB, text/plain)
2005-01-12 07:42 UTC, Miloslav Metelka

Note You need to log in before you can comment on or make changes to this bug.
Description Miloslav Metelka 2004-11-13 11:17:23 UTC
This is a successor of the issue #27138 which was
made duplicate of this issue. The new issue was
created for better clarity.
Comment 1 Miloslav Metelka 2004-11-13 11:20:15 UTC
The design view document for the editor module split is at

I would like to ask for review of the proposed solution. I hope that
fasttrack should be enough here. Thanks.
Comment 2 Miloslav Metelka 2004-11-13 11:23:27 UTC
*** Issue 27138 has been marked as a duplicate of this issue. ***
Comment 3 Jesse Glick 2004-11-14 17:06:33 UTC

- text module is no more

- is it really necessary to split the text/plain editor kit? I guess
it does no harm except increase total # of modules.

- module JAR names should now be code-name-base.jar in all cases
Comment 4 Jaroslav Tulach 2004-11-22 07:30:21 UTC
The current documentation is not accurate enough, I am affraid. As
Jesse pointed out module names are wrong. Please fix the proposal and
let us know. My requirements:

01 module names are wrong
02 what type each module is going to be - autoload, regular or eager
03 autoload modules should not have any UI or anything in layer (not
even settings) is that satisfied
04 what is the "indentation framework"?
05 what will be the public packages or each module
06 are you sure you want org.netbeans.api package? Are you ready for
the work? What will be the initial content?
07 why the Settings class cannot be moved to different package?
08 would not is be possible to have just one settings module that
would somehow read hints provided by various kits? This is real bloat
of *settings*.jars.

Btw. I think that if the basic editor module is going to be autoload,
it makes sence to register the plain kit in different module.
Comment 5 Miloslav Metelka 2004-12-14 22:23:55 UTC
I have updated the editor module split document
as necessary but I leave the issue closed as the review of the editor
module split will be done as part of the Editor APIs Documentation
review (issue #52275).

Reply to questions:
 - editor/plain will be used (not text/plain)
 - as Yarda pointed out we will make the infrastructure modules
autoloads so I think extract plain editor should be appropriate.
 - I have fixed the module names.

 ad 01) done.

 ad 02) three autoloads (highlighted in "Notes" section in the doc)

 ad 03) will be satisfied

 ad 04) will be done in a different way. We will move the java
indentation engine physically into javacore module. Java-specific
editor module will plug its indentation implementation into it using a
friend SPI.

 ad 05) I have marked currently needed public packages as bold in the
document. They should continue to be public after the split (in the
respective modules) as they are used (e.g. by JSP module) but of
course in the future I would like to revise the dependencies.
 I have not decided PP for the bookmarks submodule yet but there will
likely be one PP for a friend API (SPI will likely not be necessary).
As the bookmarks submodule will in fact contain a new functionality it
will be created after the physical split of the current editor is

 ad 06) I have removed mentioning of the org.netbeans.api (and .spi)
in the modules' packages as it adds no value (was there historically).
I can't tell now whether we will request the official stability for
anything in the editor's core infrastructure. In the future I would
like to have just the core functionality in the main editor's module
(document, views and actions infrastructures) and extract other things
(like code completion, abbrevs, macros etc.) into submodules. But this
is still a preliminary view.

 ad 07) I was not meant to be moved into different package but into
different module which IIRC cannot be done due to the NB module
classloaders preventing to have classes from a single packages in two
different modules unless you have a special exception ;)
 Actually I've changed the document and I would prefer to not create
the settings submodules immediately but instead wait for a proper
editor settings API/SPI to be developed first.

 ad 08) IMHO not as the target kits will be in the target
language-specific editor modules containing the kits registration etc.
and in fact we are doing the settings separation to not require our
language-specific editor modules. BTW I have changed the policy
regarding the "lib" modules to not produce them for small modules such
as settings (described in the doc).
Comment 6 Miloslav Metelka 2004-12-20 16:21:18 UTC
Reopening as agreed with the DevRev team previously.
I'm going to create the branch editor_split and prepare the split.
Comment 7 Miloslav Metelka 2005-01-10 18:14:42 UTC
The split is now prepared in editor_split branch.

The java editor is under java/editor.
The html editor is under html/editor.
The plain editor is under editor/plain.

I have increased the editor's module major version from 2 to 3 because
the org.netbeans.modules.editor.options was splitted in non-backward
compatible way. I have extracted the options classes (JavaOptions,
HTMLOptions and PlainOptions) plus the corresponding bean info classes
and printing options classes into the respective modules (under
options subpackage in each module).

The tests are still under the main editor module (I've just updated
test cp.extra properties) and I plan to split them as well.

I'm attaching the log from committing to the editor_split branch.
Comment 8 Miloslav Metelka 2005-01-10 18:15:43 UTC
Created attachment 19588 [details]
Commit log from committing to the editor_split branch
Comment 9 Miloslav Metelka 2005-01-12 07:41:29 UTC
The editor_split build was successfully tested so I've integrated the
editor split into the main trunk.
Comment 10 Miloslav Metelka 2005-01-12 07:42:23 UTC
Created attachment 19632 [details]
Commit log from trunk integration