Page tree
Skip to end of metadata
Go to start of metadata

Related epic in JIRA:  MAGNOLIA-7070 - Getting issue details... STATUS

What is config by code?

DSL which allows to describe our definitions in a fluent way + configuration source integration      

Configuration source (less studied at the moment)

Related issue:  MAGNOLIA-7071 - Getting issue details... STATUS
- Blossom: uses Spring bean discovery goodness to reveal the annotated classes. Happens outside of Mgnl’s normal loop and is hard to align with the concept of configuration sources.

- Spring classpath scanning alternative: do the scanning ourselves much like we do with resources! Can be done via Reflections as well as its more moderner rivals like FastClasspathUtil
— pros: some might find it funky and easy - just drop an annotated class and put all the config inside.
— cons: no enforced alignment, but main issue - go figure which module the definition belongs to? (jar=>META-INF/module.xml can be resolved via a hack, but meh...)

- 5.0 C-b-C effort: encourages modules classes to have annotated methods which accept builders as parameters and do the magic. 
pros: all the config in the well know place, easy to align the definitions with the module dependency hierarchy.
cons: the configuration gets a tad too cluttered (all the definitions get configured at the same place)
— what if the configuration would still originate from the module class from there we would be able dispatch/distribute the config?

public MyModule {
     // has a method which returns a dialog definition. Alternatively an explicit legit interface like Supplier<DialogDefinition> could be enforced
     private @Dialog CustomDialogConfig dialog;  
     // has a method which returns an app descriptor
     private @App CustomAppConfig app; 
     //…and/or…
     // just delegates configuration to a class which in turn has annotated methods like above
     private @Config configStuff;
}

The registries then would specify which annotations they are interested in.

Builders (after some fiddling)

Hands down should be generated in 2017. Some previous research has been done by Mika around a year ago: https://www.evernote.com/shard/s209/sh/a7e7948a-4606-4d64-8b8c-2adf1c642340/c32416d0a09399c7.

Findings so far

Generation tools:
- JavaPoet is pretty much the only option for code generation (used in pretty much all the annotation processing solutions, and is really nice and intuitive to use).
- Google Auto suite is also pretty useful:
service for annotation processor boilerplate (descriptors, mappings etc)
commons for the basic annotation processing + lot’s of utility
- JackDaw looks nice code-wise and seems to be quite minimalistic and clear, but doesn’t seem to work correctly and offers less re-usable utilities.

What it takes from us:
- In order for annotation processor to kick in, the types need to be… annotated. 
— annotation name is still an open question (@WithMgnlBuilder, @MgnlConfig, @MgnlBuilder, @Builder….)
— The fact we’re using and extending the configured definitions seems to be quite great for us: by means of @Inherited meta-annotation one can spread the annotation to all child classes (doesn’t work w/ interfaces)

Open questions:
— defaults
— DSL feature set 

Further plans:
- Extension via code @Inherits(id)
- Decoration via code @Decorates(id)
- Migration via code (long shot but could be an idea to also migrate any definitions from any source)
— would apply each and every time the system starts unlike the JCR one (but we can’t change ppl’s YAML and code once and for all anyway)

  • No labels