Introduce a configuration abstraction to access configuration properties in a clean and concise way

[ancho]

This is more a cleanup and refactoring Task. See comments from #300.

JBake uses apache commons CompositeConfiguration or it's interface Configuration to access configuration properties.

It's all over the place and accessed in the same way, with some constant keys defined in ConfigUtil.Keys or variable ones that may be added to the jbake.properties file like custom types.

It would be nice to have a configuration abstraction that is intialized during a configuration phase and shared between classes, validating requried properties like a source or destination folder and things like that. See a pseudo implementation of a JbakeConfiguration as an example of how it could look like.

Here is a list of Classes that make use of a CompositeConfiguration. Some of them take parameters that should be already present in the configuration.

• Asset

  • public Asset(File source, File destination, CompositeConfiguration config)

• Crawler

  • public Crawler(ContentStore db, File source, CompositeConfiguration config)

• Oven

  • public Oven(final File source, final File destination, final CompositeConfiguration config, final boolean isClearCache)

• Renderer

  • public Renderer(ContentStore db, File destination, File templatesPath, CompositeConfiguration config)

• Init

  • public Init(CompositeConfiguration config)

• CustomFSChangeListener

  • public CustomFSChangeListener(LaunchOptions res, CompositeConfiguration config)
    Uses the configuration to instantiate an Oven and pass the configuratin to the constructor

• AbstractTemplateEngine

  • protected AbstractTemplateEngine(final Configuration config, final ContentStore db, final File destination, final File templatesPath)
  • extended by
    • DelegatingTemplateEngine
    • FreemarkerTemplateEngine
    • GroovyMarkupTemplateEngine
    • GroovyTemplateEngine
    • JadeTemplateEngine
    • ThymeleafTemplateEngine

And used in different utility classes.

• Baker
  • public void bake(final LaunchOptions options, final CompositeConfiguration config)
    Instanciates an Oven and passes the config to the constructor
• FileUtil
  • public static String findExtension(CompositeConfiguration config, String docType)
    Extract a fileextension from configuration by document type
• BakeWatcher
  • public void start(final LaunchOptions res, CompositeConfiguration config)
    Start a file watcher using the content path read from the configuration
• Main
  • protected void run(LaunchOptions res, CompositeConfiguration config)
    Called from main method inderectly by loading configuration from properties file
• RenderingTool
  • int render(Renderer renderer, ContentStore db, File destination, File templatesPath, CompositeConfiguration config)
  • interface implemented by
    • ArchiveRenderer
    • DocumentsRenderer
    • FeedRenderer
    • IndexRenderer
    • SitemapRenderer
    • TagsRenderer
• ParserEngine
  • Map<String, Object> parse(Configuration config, File file, String contentPath)
  • interface implemented by
    • MarkupEngine
      • public Map<String, Object> parse(Configuration config, File file, String contentPath)
      • private void processHeader(Configuration config, List<String> contents, final Map<String, Object> content)
      • extended by
        • AsciidoctorEngine
        • ErrorEngine
        • MarkdownEngine
        • RawMarkupEngine

[ottlinger]

@ancho Thanks, would it make sense to rely on existing solutions for Configuration management such as
http://tamaya.incubator.apache.org/ ?

[ancho]

Hi @ottlinger. Interesting project. But I don't think there is any need to replace a configuration solution with another one yet. I think it's more a matter of cleaning up the code. To make it possible to replace the configuration solution with ease at later time, without touching all the places already coupled with the CompositeConfiguration class.

[ancho]

Hmm. After reading more about tamaya I got curious. I will give it a try.

[ancho]

Ok. So I decided to cleanup the configuration of jbake and it's components.

@ottlinger I didn't use tamaya. And I know that Jon is careful of adding external dependencies to the project, which is fine. tamaya is in longtime incubating mode as it seems.

But if you like, you can fork my branch and show an alternative with tamaya as a proof of concept.

https://github.com/ancho/jbake/tree/feature/configuration-refactoring

[ottlinger]

@ancho Thanks for your comments, we are working on a new release of Tamaya with a new homepage. The upcoming version 0.3-incubating contains loads of new features.

[ancho]

closed by #341