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.
These dependencies exist because of per-project formatting settings.
Btw, it looks like the main issue is module projectuiapi which declares in manifest too strong reqs:
Probably this issue could be discussed with project UI API team and they can weaken dependency to OpenIDE-Module-Recommends?
Any plans on this?
Alexey have completed split on CND side and this issue is the last blocker :-)
(In reply to comment #3)
> Any plans on this?
No, sorry. I recommend escalating this through the internal planning process for 6.9.
Ok. Will do
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.
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.
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
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:
<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"/>
(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.)
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
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.
Ok, I'll have a look and see what can be done. I also added it to http://wiki.netbeans.org/EditorPlan69
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?
(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.
Do not add <build-prerequisite/> and <compile-dependency/> when you are not even changing source code. Just <run-dependency> would suffice.
(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.
Integrated into 'main-golden', will be available in build *201001131418* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
User: Vita Stejskal <email@example.com>
Log: #178311: moving project type specific registrations to their impl modules
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.
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
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.
Vita, thank you for the patch! I'll try it today.
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!
(In reply to comment #23)
> It works.
That's good news. Thanks
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.
(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.
[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.
Created attachment 94390 [details]
The full patch
[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.
JG01b - sure, could be done later if it makes sense.
Thanks for the review. I'm going to integrate.
local changeset: 0f909786f965
Integrated into 'main-golden', will be available in build *201002240200* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
User: Vita Stejskal <firstname.lastname@example.org>
Log: #178311: separating project related stuff from the rest of the editor infrastructure