Skip to main content
Jump to: navigation, search

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

(All modules: modifications after ECE)
(All modules)
Line 17: Line 17:
  
 
'''Possible actions:'''
 
'''Possible actions:'''
 +
* (Actions are en/disabled depending on selection)
 
* Add a module (from those contained in JRE but not included by default, or previously removed)
 
* 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)
 
* Remove a module (applies only to JRE modules, other modules should be removed on the Libraries or Projects tab)

Revision as of 16:50, 28 October 2018

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:

ModuleGraph page.png

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:
    • S = System Library
    • U = Upgrade of a System Library
    • A = Automodule
    • > = Tweaked (see "Details")
  • the origin - not enough space here, perhaps under Details
  • ...

Possible actions:

  • (Actions are en/disabled depending on selection)
  • 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)
    • 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.

Details

For the selected module we can

  • Inspect the declared details (from module-info: exports/opens/requires). Collapsed in the mockup.
  • Add any of the following tweaks:
    • Let the module expose an existing package (export and/or open), possibly restricted to certain modules.
    • Let the module read another module
    • Add more sources to patch the module, one of:
      • A source folder
      • A project
      • A jar (does it make sense to let one 3rd party thing patch another 3rd party thing?)

UX Discussion

  • 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.
  • I've been thinking about making "All modules" a full dependency tree.
    • 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
  • The two compartments are essentially master-detail, but 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")
  • 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?
  • The Details compartment is a table, 2nd column being initially filled from tiny dialogs behind the buttons Expose Package / Read Module....
    • Perhaps exports / opens can be configured inline by use of a drop-down.
    • Restrictions of exports / opens could be listed by child nodes (modules), then the label could, e.g., by "opened selectively"
  • 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.
  • Placement of the buttons could be debated: top two buttons only relate to the left compartment, next three only to the right compartment, but a four column design (list, buttons, table, buttons) wastes a lot of space ...

Tests

  • Many aspects of the above should consider the distinction main/test sources, how exactly is a tricky question.
    • Each modification could have a flag main/test and be visualized with the same colors as in the package explorer
    • Alternatively, the entire page could have two filtered views, selectable by a drop down [main/test].
      • Changes made in view "main" are global
      • Changes made in view "test" are not visible in view "main"

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.

  • 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? ...)
  • --add-reads is now universally applicable, we just need to add support for the "module" ALL-UNNAMED.
  • Test code could read ALL-UNNAMED by default, with the option to remove this.
  • 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