Statement

We support typical module "domain" definitions, such as apps, dialogs, reusing the already existing registry-provider pattern.
Resulting config is loaded in memory.

On the table

• Domain definitions
  
  •  define what domain definitions are (e.g. anything that has a definition VS. anything that can be configured under a module...)
• Coverage of "unmapped" config
  
  • config nodes that are not bound to a definition
  • Probably no silver-bullet but would be nice to have a general mechanism for that too
    
    • e.g. filters, applauncher layout
    • needs to provide individual entries + ordering
• Make observation manager file-aware
  
  • java 7 can natively observe the file system
  • http://docs.oracle.com/javase/7/docs/api/java/nio/file/Path.html#register(java.nio.file.WatchService,%20java.nio.file.WatchEvent.Kind%5B%5D,%20java.nio.file.WatchEvent.Modifier...)
  • might state that file observation is java 7-only
  • code-awareness? hot-redeploys?
• Bean representation
  
  • We need an abstract representation for config beans
    
    • folders, nodes, properties
      
      • wording is ideally independent from JCR notation
    • to be used in the Vaadin containers
      
      • what icon to use
  • Hold origin info — where beans were loaded from (file, JCR, code)
    
    • class and origin/path
    •  has to be per property, no?
  • All X's need to have the same notion of id/path
    
    • tell what "element" you're overriding?
    • when using a n2b extends, only properties from the top-most definition are accounted for
    • we don't need to combine definitions/interfaces as mixins
• Decoration
  
  • Today merge/decoration can be done only from/to JCR (extends, override)
  • Has to happen in memory now
• Places where we're relying on JCR today
  
  • can they stay or do they have to operate on memory now?
  • need an overview what these are
    
    • server configuration is in JCR only — it's basically a one by instance thingy
    • typical registries (dialogs, apps, ...) should be suited for any additional providers
      

Config by JCR

• Not all definitions are interfaces right now
  • ideally to be changed

Config by Code

• Investigate what generation mechanism could/should be used (involve Architects/Greg)
•  Clarify where to place generated classes
  
  • check how to use definition impls e.g. in tests then (might not be around after a mvn clean)
• Use convention over configuration

Config by File

• File residence
  
  • File loader should support both config files in jar and from filesystem
  •  needs good convention
    
    • keep the config files close to the template scripts
• Format
  
  • Jackson lib seems powerful, supports a whole range of formats (https://github.com/FasterXML/jackson)

Not on the table now

• Publication of in memory config
  
  • we only consider getting config in jcr, code or file from author to public...
• We do not need to support just any config
• Showing the consolidated config won't be a JCR content app anymore