Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "Java9/ModularityOptions/UIProposal SH"

m (All modules)
("see also" added where the resulting feature is documented.)
 
(9 intermediate revisions by the same user not shown)
Line 1: Line 1:
I've been painting a bit and here is my first sketch to support all module-graph related options in one tab of the Java Build Path properties page:
+
{{Note|Redesign of UI to support all module-graph related options in one tab of the Java Build Path properties page.
  
[[File:ModuleGraph page.png]]
+
Following a discussion at EclipseCon Europe 2018, this started with a painted mock-up and a list of requirements.
 +
 
 +
During the 4.12 development cycle a first version of this feature was implemented via {{FixedBug|546352}} and later polished in and around {{FixedBug|546797}}.}}
 +
 
 +
'''See also:'''
 +
* [https://www.eclipse.org/eclipse/news/4.12/jdt.php#buildpath-module-dependencies 4.12 New and Noteworthy]
 +
* [https://help.eclipse.org/2019-06/topic/org.eclipse.jdt.doc.user/reference/ref-properties-build-path.htm#module-dependencies Online Help]
 +
* [https://www.youtube.com/watch?v=UUQoQtKgaWc ECE 2019 Presentation]
 +
 
 +
 
 +
[[File:ModuleGraph page.png||Original Sketch]] [[File:ModuleDependencies page.png|870px|Current Implementation]]
 +
 
 +
{|class="wikitable"
 +
|[[Image:Ok_green.gif]]
 +
|Implemented.
 +
|-
 +
|[[Image:Progress.gif]]
 +
|Deferred, candidate for second iteration.
 +
|-
 +
|[[Image:Glass.gif]]
 +
|Deferred, investigation needed.
 +
|}
  
 
==All modules==
 
==All modules==
Line 9: Line 30:
 
'''It shows the following additional information:'''
 
'''It shows the following additional information:'''
 
* icon decorations:
 
* icon decorations:
** S = System Library
+
** [[Image:Ok_green.gif]] S = System Library
** U = Upgrade of a System Library
+
** [[Image:Progress.gif]] U = Upgrade of a System Library
** A = Automodule
+
** [[Image:Ok_green.gif]] A = Automodule
** > = Tweaked (see "Details") ''if we follow conventions of SCM decorations, then this is a prefix of the label''
+
** [[Image:Ok_green.gif]] > = Tweaked (see "Details") -- following conventions of SCM decorations, then this is a prefix of the label
 
* <strike>the '''origin'''</strike> - not enough space here, perhaps under Details
 
* <strike>the '''origin'''</strike> - not enough space here, perhaps under Details
 
* ...
 
* ...
  
 
'''Possible actions:'''
 
'''Possible actions:'''
* (Actions are en/disabled depending on selection)
+
* [[Image:Ok_green.gif]] (Actions are en/disabled depending on selection)
* Add a module (from those contained in JRE but not included by default, or previously removed)
+
* [[Image:Ok_green.gif]] Add a module (from those contained in JRE but not included by default, or previously removed)
* Remove a module (applies only to JRE modules, other modules should be removed on the Libraries or Projects tab)
+
* [[Image:Ok_green.gif]] Remove a module (applies only to JRE modules, other modules should be removed on the Libraries or Projects tab)
 
** Is that restriction confusing? Alternative: when removing a module explicitly listed on the Modulepath, warn before removing.
 
** Is that restriction confusing? Alternative: when removing a module explicitly listed on the Modulepath, warn before removing.
* Select any module for additional tweaking, see next.
+
* [[Image:Ok_green.gif]] Select any module for additional tweaking, see next.
  
 
==Details==
 
==Details==
 
For the selected module we can
 
For the selected module we can
* Inspect the declared details (from module-info: exports/opens/requires). Collapsed in the mockup.
+
* [[Image:Ok_green.gif]] Inspect the declared details (from module-info: exports/opens/requires). Collapsed in the mockup.
 
* Add any of the following tweaks:
 
* Add any of the following tweaks:
** Let the module expose an existing package (export and/or open), possibly restricted to certain modules.
+
** [[Image:Ok_green.gif]] Let the module expose an existing package (export and/or open), possibly restricted to certain modules.
** Let the module read another module
+
** [[Image:Ok_green.gif]] Let the module read another module
** Add more sources to patch the module, one of:
+
** [[Image:Ok_green.gif]] Add more sources to patch the module, one of:
*** A source folder
+
*** [[Image:Ok_green.gif]] A source folder
*** A project
+
*** [[Image:Ok_green.gif]] A project
*** A jar (does it make sense to let one 3rd party thing patch another 3rd party thing?)
+
*** [[Image:Progress.gif]] A jar (does it make sense to let one 3rd party thing patch another 3rd party thing?)
 
* Icon decorations:
 
* Icon decorations:
** E = Exports
+
** [[Image:Ok_green.gif]] E = Exports
** O = Opens
+
** [[Image:Ok_green.gif]] O = Opens
** R = Reads
+
** [[Image:Ok_green.gif]] R = Reads
** P = Patched by
+
** [[Image:Ok_green.gif]][[File:Patch_ovr.png|baseline]] = Patched
  
 
==UX Discussion==
 
==UX Discussion==
 +
 
* [[Image:Ok_green.gif]] We still need second level dialogs for details for each of the actions (except remove :) ), but we no longer need the three levels of dialogs that we currently use.
 
* [[Image:Ok_green.gif]] We still need second level dialogs for details for each of the actions (except remove :) ), but we no longer need the three levels of dialogs that we currently use.
 
* [[Image:Progress.gif]] I've been thinking about making "All modules" a full dependency tree => ''option is nice-to-have, deferred''.
 
* [[Image:Progress.gif]] I've been thinking about making "All modules" a full dependency tree => ''option is nice-to-have, deferred''.
Line 49: Line 71:
 
** only main modules (i.e., no test-only dependencies)
 
** only main modules (i.e., no test-only dependencies)
 
* [[Image:Ok_green.gif]] The two compartments are essentially master-detail
 
* [[Image:Ok_green.gif]] The two compartments are essentially master-detail
** [[Image:Progress.gif]] After adding a reads module under Details, it is likely that details for that module need to be added next. So perhaps some navigation from right to left is useful, too ("Select in All Modules") ''deferred''
+
** [[Image:Ok_green.gif]] After adding a reads module under Details, it is likely that details for that module need to be added next. Double click on the RHS selects the module in the LHS list.
 
* ''withdrawn'': <strike>I played with arrow up/down icons to signify the two directions: exposing packages '''to''' other modules, and reading '''from''' other another module. Import/Export wizards, e.g., use diagonal arrows, is that better?</strike>  
 
* ''withdrawn'': <strike>I played with arrow up/down icons to signify the two directions: exposing packages '''to''' other modules, and reading '''from''' other another module. Import/Export wizards, e.g., use diagonal arrows, is that better?</strike>  
 
* ''withdrawn'': <strike>The Details compartment is a table, 2nd column being initially filled from tiny dialogs behind the buttons '''Expose Package''' / '''Read Module...'''.</strike>
 
* ''withdrawn'': <strike>The Details compartment is a table, 2nd column being initially filled from tiny dialogs behind the buttons '''Expose Package''' / '''Read Module...'''.</strike>
 
* [[Image:Ok_green.gif]] Qualifications of exports / opens are listed as child nodes (modules), has-child indicator should suffice to signal the qualification
 
* [[Image:Ok_green.gif]] Qualifications of exports / opens are listed as child nodes (modules), has-child indicator should suffice to signal the qualification
* ?? For patching, I would intuitively expect only one pattern: add a source folder of the current project into a given module on the module path.
+
* [[Image:Glass.gif]]  For patching, I would intuitively expect only one pattern: add a source folder of the current project into a given module on the module path.
 
** For maximum flexibility we could also support to patch a module with another project, or just a source folder of that project.
 
** For maximum flexibility we could also support to patch a module with another project, or just a source folder of that project.
 
** Till suggested to only support project (meaning: all its source folders)
 
** Till suggested to only support project (meaning: all its source folders)
* [[Image:Ok_green.gif]] when patching a module, that patched module should move to the top of the LHS list (it is now the current module)
+
* [[Image:Progress.gif]] when patching a module, that patched module should move to the top of the LHS list (it is now the current module)
  
 
===Tests===
 
===Tests===
 
* Many aspects of the above should consider the distinction main/test sources, how exactly is a tricky question.
 
* Many aspects of the above should consider the distinction main/test sources, how exactly is a tricky question.
** [[Image:Ok_green.gif]] Each modification dialog will have a checkbox "[x] Test only".
+
** [[Image:Progress.gif]] Each modification dialog will have a checkbox "[x] Test only". ''(agreed but not implemented)''
** [[Image:Progress.gif]] Alternatively, the entire page could have two filtered views, selectable by a drop down [main/test] - ''deferred / may not be needed due to individual checkboxes in dialogs''
+
** [[Image:Glass.gif]] Alternatively, the entire page could have two filtered views, selectable by a drop down [main/test] - ''deferred / may not be needed due to individual checkboxes in dialogs''
 
*** Changes made in view "main" are global
 
*** Changes made in view "main" are global
 
*** Changes made in view "test" are not visible in view "main"
 
*** Changes made in view "test" are not visible in view "main"
** [[Image:Ok_green.gif]] Use dark gray icons like in Package Explorer
+
** [[Image:Progress.gif]] Use dark gray icons like in Package Explorer ''(agreed but not implemented)''
  
 
==Functionality Discussion==
 
==Functionality Discussion==
 
I do hope that this one page can eventually fully replace the existing Module dialog (hidden behind "Is modular"), and also cover the additional use cases discussed above.
 
I do hope that this one page can eventually fully replace the existing Module dialog (hidden behind "Is modular"), and also cover the additional use cases discussed above.
* We seem to loose the visualization of explicitly and implicitly included modules, so, we'd have to make up our minds what happens if the user tries to remove a module that is implicitly included because another included module depends on it (refuse to remove? remove with full path of incoming dependencies? ...)
+
* [[Image:Ok_green.gif]] We are loosing the visualization of explicitly and implicitly included modules. Instead the "Remove" button triggers computing the minimal closure for removal (and asks for confirmation). Similarly "Add System Module..." auto-selects all required modules.
* <code>--add-reads</code> is now universally applicable, we just need to add support for the "module" '''ALL-UNNAMED'''.
+
* [[Image:Progress.gif]] <code>--add-reads</code> is now universally applicable, we just need to add support for the "module" '''ALL-UNNAMED'''. ''(agreed but not implemented)''
 
* Test code could read '''ALL-UNNAMED''' ''by default'', with the option to remove this.
 
* Test code could read '''ALL-UNNAMED''' ''by default'', with the option to remove this.
* Still missing: a location to specify the '''Main Class''' :(
+
* [[Image:Ok_green.gif]] To reflect "--add-modules ALL-SYSTEM" the "Add System Module" dialog will have a checkbox "[x] All System Modules".
 +
** Currently spelling out all modules in the classpath attribute -- may want to reduce it to the constant ALL-SYSTEM, indeed.
 +
* [[Image:Glass.gif]] Still missing: a location to specify the '''Main Class''' :(
  
 
==Future==
 
==Future==
 
For test specific tweaks (which are in general not ''migration'' tools, but part of the architecture) I would still wish we had s.t. that looks like source code, easily compared in git etc. Is the proposed design blocking such future development?
 
For test specific tweaks (which are in general not ''migration'' tools, but part of the architecture) I would still wish we had s.t. that looks like source code, easily compared in git etc. Is the proposed design blocking such future development?
 
* One might think of making the "test" view read-only in the dialog, and redirect to a special module-info.java for editing (comparable to [https://github.com/apache/maven-plugins/pull/139/commits/d7d79817ae6f85a802cf73793403e5a1c131fa42 compiler-jpms-test/src/test/java/module-info.java])
 
* One might think of making the "test" view read-only in the dialog, and redirect to a special module-info.java for editing (comparable to [https://github.com/apache/maven-plugins/pull/139/commits/d7d79817ae6f85a802cf73793403e5a1c131fa42 compiler-jpms-test/src/test/java/module-info.java])

Latest revision as of 13:42, 19 November 2019

Note.png
Redesign of UI to support all module-graph related options in one tab of the Java Build Path properties page.

Following a discussion at EclipseCon Europe 2018, this started with a painted mock-up and a list of requirements.

During the 4.12 development cycle a first version of this feature was implemented via bug 546352 and later polished in and around bug 546797.


See also:


Original Sketch Current Implementation

Ok green.gif Implemented.
Progress.gif Deferred, candidate for second iteration.
Glass.gif Deferred, investigation needed.

All modules

This compartment lists all modules that are contained in the module graph. The module defined by the current project is pinned to the top of the list. Other modules are sorted alphabetically.

It shows the following additional information:

  • icon decorations:
    • Ok green.gif S = System Library
    • Progress.gif U = Upgrade of a System Library
    • Ok green.gif A = Automodule
    • Ok green.gif > = Tweaked (see "Details") -- following conventions of SCM decorations, then this is a prefix of the label
  • the origin - not enough space here, perhaps under Details
  • ...

Possible actions:

  • Ok green.gif (Actions are en/disabled depending on selection)
  • Ok green.gif Add a module (from those contained in JRE but not included by default, or previously removed)
  • Ok green.gif Remove a module (applies only to JRE modules, other modules should be removed on the Libraries or Projects tab)
    • Is that restriction confusing? Alternative: when removing a module explicitly listed on the Modulepath, warn before removing.
  • Ok green.gif Select any module for additional tweaking, see next.

Details

For the selected module we can

  • Ok green.gif Inspect the declared details (from module-info: exports/opens/requires). Collapsed in the mockup.
  • Add any of the following tweaks:
    • Ok green.gif Let the module expose an existing package (export and/or open), possibly restricted to certain modules.
    • Ok green.gif Let the module read another module
    • Ok green.gif Add more sources to patch the module, one of:
      • Ok green.gif A source folder
      • Ok green.gif A project
      • Progress.gif A jar (does it make sense to let one 3rd party thing patch another 3rd party thing?)
  • Icon decorations:
    • Ok green.gif E = Exports
    • Ok green.gif O = Opens
    • Ok green.gif R = Reads
    • Ok green.gifPatch ovr.png = Patched

UX Discussion

  • Ok green.gif We still need second level dialogs for details for each of the actions (except remove :) ), but we no longer need the three levels of dialogs that we currently use.
  • Progress.gif I've been thinking about making "All modules" a full dependency tree => option is nice-to-have, deferred.
    • Confer: M2e has both: a tree starting from a fixed set of roots plus a flat list of transitive dependencies
    • Roots are currently implicit in JDT
    • Could possibly be made a view option later
  • Progress.gif Filtering could be added later:
    • only modified modules
    • only main modules (i.e., no test-only dependencies)
  • Ok green.gif The two compartments are essentially master-detail
    • Ok green.gif After adding a reads module under Details, it is likely that details for that module need to be added next. Double click on the RHS selects the module in the LHS list.
  • withdrawn: I played with arrow up/down icons to signify the two directions: exposing packages to other modules, and reading from other another module. Import/Export wizards, e.g., use diagonal arrows, is that better?
  • withdrawn: The Details compartment is a table, 2nd column being initially filled from tiny dialogs behind the buttons Expose Package / Read Module....
  • Ok green.gif Qualifications of exports / opens are listed as child nodes (modules), has-child indicator should suffice to signal the qualification
  • Glass.gif For patching, I would intuitively expect only one pattern: add a source folder of the current project into a given module on the module path.
    • For maximum flexibility we could also support to patch a module with another project, or just a source folder of that project.
    • Till suggested to only support project (meaning: all its source folders)
  • Progress.gif when patching a module, that patched module should move to the top of the LHS list (it is now the current module)

Tests

  • Many aspects of the above should consider the distinction main/test sources, how exactly is a tricky question.
    • Progress.gif Each modification dialog will have a checkbox "[x] Test only". (agreed but not implemented)
    • Glass.gif Alternatively, the entire page could have two filtered views, selectable by a drop down [main/test] - deferred / may not be needed due to individual checkboxes in dialogs
      • Changes made in view "main" are global
      • Changes made in view "test" are not visible in view "main"
    • Progress.gif Use dark gray icons like in Package Explorer (agreed but not implemented)

Functionality Discussion

I do hope that this one page can eventually fully replace the existing Module dialog (hidden behind "Is modular"), and also cover the additional use cases discussed above.

  • Ok green.gif We are loosing the visualization of explicitly and implicitly included modules. Instead the "Remove" button triggers computing the minimal closure for removal (and asks for confirmation). Similarly "Add System Module..." auto-selects all required modules.
  • Progress.gif --add-reads is now universally applicable, we just need to add support for the "module" ALL-UNNAMED. (agreed but not implemented)
  • Test code could read ALL-UNNAMED by default, with the option to remove this.
  • Ok green.gif To reflect "--add-modules ALL-SYSTEM" the "Add System Module" dialog will have a checkbox "[x] All System Modules".
    • Currently spelling out all modules in the classpath attribute -- may want to reduce it to the constant ALL-SYSTEM, indeed.
  • Glass.gif Still missing: a location to specify the Main Class :(

Future

For test specific tweaks (which are in general not migration tools, but part of the architecture) I would still wish we had s.t. that looks like source code, easily compared in git etc. Is the proposed design blocking such future development?

Back to the top