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 178311 - remove projectapi and projectuiapi dependencies from options.editor
Summary: remove projectapi and projectuiapi dependencies from options.editor
Status: RESOLVED FIXED
Alias: None
Product: editor
Classification: Unclassified
Component: Options (show other bugs)
Version: 6.x
Hardware: All All
: P2 normal with 1 vote (vote)
Assignee: Vitezslav Stejskal
URL:
Keywords: API, API_REVIEW_FAST
Depends on:
Blocks:
 
Reported: 2009-12-08 10:32 UTC by Alexey Vladykin
Modified: 2010-02-23 22:08 UTC (History)
3 users (show)

See Also:
Issue Type: TASK
Exception Reporter:


Attachments
The full patch (131.92 KB, patch)
2010-02-18 03:09 UTC, Vitezslav Stejskal
Details | Diff
The api changes only (102.52 KB, patch)
2010-02-18 03:28 UTC, Vitezslav Stejskal
Details | Diff
The full patch (131.80 KB, patch)
2010-02-22 10:15 UTC, Vitezslav Stejskal
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Alexey Vladykin 2009-12-08 10:32:39 UTC
We need to extract C/C++ editor support from CND for standalone DLight. The less module dependencies we pull in, the better.
Standalone DLight does not need projects, so it would be nice not to pull in the corresponding modules -- projectapi nad projectuiapi. But currently they are required by options.editor.

Is it possible to remove this dependency, e.g. by moving project-aware parts of editor options to another module?

BTW, editor.indent also depends on projectapi, and it would be nice to remove this dependency as well.
Comment 1 Vitezslav Stejskal 2009-12-08 10:43:21 UTC
These dependencies exist because of per-project formatting settings.
Comment 2 Vladimir Voskresensky 2009-12-08 23:32:26 UTC
Btw, it looks like the main issue is module projectuiapi which declares in manifest too strong reqs:
OpenIDE-Module-Needs: org.netbeans.modules.project.uiapi.ActionsFactory,
    org.netbeans.modules.project.uiapi.OpenProjectsTrampoline,
    org.netbeans.modules.project.uiapi.ProjectChooserFactory

Probably this issue could be discussed with project UI API team and they can weaken dependency to  OpenIDE-Module-Recommends?
Comment 3 Vladimir Voskresensky 2009-12-14 10:39:32 UTC
Hi,
Any plans on this? 
Alexey have completed split on CND side and this issue is the last blocker :-)

Thanks!
Vladimir
Comment 4 Vitezslav Stejskal 2009-12-15 04:02:06 UTC
(In reply to comment #3)
> Hi,
> Any plans on this? 

No, sorry. I recommend escalating this through the internal planning process for 6.9.
Comment 5 Vladimir Voskresensky 2009-12-15 10:05:52 UTC
Ok. Will do
Comment 6 David Strupl 2009-12-21 00:42:18 UTC
Vladimir,
if the only issue is that the module changes its dependency type to OpenIDE-Module-Recommends I suggest that you actually move this issue from editor to projectui owners (Product: projects).

If some more work should be done in the editor area I will put it into editor plan for 6.9.

David
Comment 7 Vladimir Voskresensky 2009-12-21 03:35:29 UTC
Hi David,
changing type of dependency was just a proposal/workaround :-)
Because in that case users of editor infrastructure have to stay with project API modules anyway (only impl modules would be detached).

I think the right solution is to fix it on editor side by introducing editor-project bridge and move dependency there.
Comment 8 Vladimir Voskresensky 2009-12-21 03:39:27 UTC
Btw, currently FormattingCustomizerPanel has "knowledge" about Maven, Ant-base and J2SE projects. Is it correct? Shouldn't registration of Formatting panel be the part of corresponding project support modules.

It would be great to have possibility and declaratively insert Formatting page into any project and do it out of options.editor module
Comment 9 Jan Lahoda 2009-12-21 07:01:15 UTC
AFAIK, the formatting panel can be used for any project type that uses ProjectCustomizer.createCustomizerDialog(String, Lookup, String, ActionListener, HelpCtx) to create its customizer. This should register the panel for such a project:
    <folder name="Projects">
        <folder name="<project-type-id>">
            <folder name="Customizer">
                <file name="Formatting.instance">
                    <attr name="instanceOf" stringvalue="org.netbeans.spi.project.ui.support.ProjectCustomizer$CompositeCategoryProvider"/>
                    <attr name="instanceCreate" methodvalue="org.netbeans.modules.options.indentation.FormattingCustomizerPanel.createCategoryProvider"/>
                    <attr name="allowedMimeTypes" stringvalue="<mime-types-supported-by-project>"/>
                    <attr name="position" intvalue="1000"/>
                </file>
            </folder>
        </folder>
    </folder>

(I think that the three project types are listed directly in options.editor for historical reasons, they were originally in the layer of this project, and were converted to annotation during some rewrite to annotation based API.)
Comment 10 Vladimir Voskresensky 2009-12-21 07:36:05 UTC
Jan, what do you think? 
Is it correct place to have registration in editor or in project-support module?
I'd vote for the second.

But it does not remove dependency from editor to project modules if impl is in options.editor
Comment 11 Jan Lahoda 2009-12-21 07:41:03 UTC
Well, I did not say that the registration in options.editor is correct. I think that simple noone so far felt strongly enough about this to fix that, so feel free to fix that yourself.
Comment 12 Vitezslav Stejskal 2009-12-22 06:09:57 UTC
Ok, I'll have a look and see what can be done. I also added it to http://wiki.netbeans.org/EditorPlan69
Comment 13 Vladimir Voskresensky 2009-12-22 06:12:17 UTC
Vita, Thanks!
Comment 14 Peter Nabbefeld 2009-12-22 07:26:58 UTC
Just a note:
Cannot find anything about FormattingCustomizerPanel - seems to be internal (e.g. friend-only). Could You, please, make it public, when moving to project-support, and add some docs for it?
Comment 15 Vitezslav Stejskal 2010-01-12 07:49:53 UTC
(In reply to comment #9)
> AFAIK, the formatting panel can be used for any project type 
> [...]
> (I think that the three project types are listed directly in options.editor for
> historical reasons, they were originally in the layer of this project, and were
> converted to annotation during some rewrite to annotation based API.)

I fixed that - http://hg.netbeans.org/jet-main/rev/e32a4cd863a4.
Comment 16 Jesse Glick 2010-01-12 22:45:42 UTC
Do not add <build-prerequisite/> and <compile-dependency/> when you are not even changing source code. Just <run-dependency> would suffice.
Comment 17 Vitezslav Stejskal 2010-01-13 04:04:38 UTC
(In reply to comment #16)
> Do not add <build-prerequisite/> and <compile-dependency/> when you are not
> even changing source code. Just <run-dependency> would suffice.

Ok, I'm sorry.
Comment 18 Quality Engineering 2010-01-13 12:26:51 UTC
Integrated into 'main-golden', will be available in build *201001131418* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/e32a4cd863a4
User: Vita Stejskal <vstejskal@netbeans.org>
Log: #178311: moving project type specific registrations to their impl modules
Comment 19 Vitezslav Stejskal 2010-02-18 03:09:21 UTC
Created attachment 94271 [details]
The full patch

This patch eliminates dependencies on projects from editor.indent and options.editor. The patch also includes API changes needed for the separation. I'll try to isolate the API changes to a separate patch for the purpose of api review.
Comment 20 Vitezslav Stejskal 2010-02-18 03:13:13 UTC
Alexey, Vladimir, could you please apply the full patch to your codebase and check that the elimination of project-related dependencies from the editor.indent and options.editor modules works for standalone DLight as you expected? I'd like to make sure that these were all the project related dependencies that needed eliminating. Thanks
Comment 21 Vitezslav Stejskal 2010-02-18 03:28:37 UTC
Created attachment 94274 [details]
The api changes only

This patch contains only the API changes. It's shorter that the full patch and so better for API review.
Comment 22 Alexey Vladykin 2010-02-18 03:35:26 UTC
Vita, thank you for the patch! I'll try it today.
Comment 23 Alexey Vladykin 2010-02-18 04:40:37 UTC
It works. With this patch Standalone DLight is able to display highlighted C/C++ code while not loading any project system modules.
Many thanks Vita and all involved!
Comment 24 Vitezslav Stejskal 2010-02-18 04:51:45 UTC
(In reply to comment #23)
> It works. 
That's good news. Thanks
Comment 25 Vitezslav Stejskal 2010-02-18 04:52:15 UTC
There were two API changes needed in order to separate projects related stuff from the editor.indent and options.editor module. Please review the changes in the attached (api changes only) patch. They are also summarized below:

1. (editor.indent): There is CodeStylePreferences class, which provides access to the formatting settings storage. This storage can either be in MimeLookup or in a project. The access is provided in the form of java.util.prefs.Preferences and the implementation automatically (depending on user's choice) provides Preferences instance backed up by MimeLookup or a project. The API change includes a new CodeStylePreferences.Provider interface, which is implemented by ProjectAwareCodeStylePreferences in editor.indent.project module and registered in META-INF/services. The editor.indent module recommends o.n.m.e.i.spi.CodeStylePreferences.Provider token, which is provided by editor.indent.project module. If no CSP.Provider implementation is found CodeStylePreferences delegates to the default formatting settings storage, which is MimeLookup.

2. (options.editor): This module used to contain FormattingPanelCustomizer, which implements the 'Formatting' panel for project properties dialogs. Modules use this class's public 'createCategoryProvider' method in their XML layer to add the 'Formatting' panel to their project's properties dialog. This class was moved to editor.indent.project module (non-public package) and new Customizers.createFormattingCategoryProvider(Map) was created. In order to preserve backwards compatibility there is a module-auto-deps.xml and META-INF/netbeans/translate.names with appropriate contents in options.editor module. The XML layers of modules in netbeans codebase were updated to use the new method (see the full patch).

I'll update the arch.xml in editor.indent.project before the final push.
Thanks
Comment 26 Jesse Glick 2010-02-18 10:02:21 UTC
(In reply to comment #25)
> If no CSP.Provider implementation is found
> CodeStylePreferences delegates to the default formatting settings storage,
> which is MimeLookup.

[JG01] Normal query style is to ask all providers in default lookup for an answer in turn, then fall back to MimeLookup. This would permit third-party modules to offer special formatting information for some projects, e.g. in case checkstyle.xml can be found in the project root dir. I would also expect the project to be able to supply a CodeStylePreferences.Provider in its lookup in case it prefers to use a different storage format, e.g. settings in pom.xml.
Comment 27 Vitezslav Stejskal 2010-02-18 13:11:50 UTC
[JG01a] Re. asking all providers in default lookup - I'll change the code to follow this style.

[JG01b] Re. looking for providers in project's lookup - I'll try to do this as well, but it may be more complicated. And since the current implementation does not support this either I wouldn't consider this a stopper.

Thanks for reviewing this Jesse.
Comment 28 Vitezslav Stejskal 2010-02-22 10:15:14 UTC
Created attachment 94390 [details]
The full patch

[JG01a] Done
[JG01b] As suspected this isn't that easy. Mainly due to the fact that project formatting settings contains the switch, which says what formatting settings should be used (project vs. global). I'm leaving this open until there is a real need for this and a specific usecase that I can implement and test.
Comment 29 Jesse Glick 2010-02-22 11:26:39 UTC
JG01b - sure, could be done later if it makes sense.
Comment 30 Vitezslav Stejskal 2010-02-23 05:28:09 UTC
Thanks for the review. I'm going to integrate.
Comment 31 Vitezslav Stejskal 2010-02-23 05:28:54 UTC
local changeset: 0f909786f965
Comment 32 Quality Engineering 2010-02-23 22:08:35 UTC
Integrated into 'main-golden', will be available in build *201002240200* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/0f909786f965
User: Vita Stejskal <vstejskal@netbeans.org>
Log: #178311: separating project related stuff from the rest of the editor infrastructure