Rendering modularization

[melix]

Hi!

This is a pretty big pull request that refreshes the rendering architecture. With this patch:

• JBake uses an internal, potentially in memory, database to store documents converted from markup engines
• if using a local dabatase (default), then JBake now only renders pages that have changed
• rendering can be forced using the --reset command line option
• rendering will be forced if the templates change
• separation of the template engine from core, making Freemarker optional
• added an alternative, optional, Groovy template engine
• template engines have access to the database, which means they can optimize memory usage (depending on the underlying engine, more difficult to do with Freemarker)
• "index", "archive", "feed" are now considered as document types, meaning you can use them as you would use "page" or "post"
• tags are still rendered with special handling
• support for custom document types. The list of document types is extracted from the configuration file (template.[doctype].file

Comments welcome!

[melix]

Actually the case where you need to flush the cache is more complex than just a template change. Take the index, for example. It depends on the list of posts, so if you add a post, you need to re-render the index. The caching strategy should ideally handle that, even if you can force rendering with --reset.

[jonbullock]

@melix I'll have a look at that when I finally get round to merging this in.

[melix]

Regarding the caching issue, I'm wondering if adding a jbake-render: always meta tag wouldn't help. In that case, the index would for example have that flag, forcing it to always be rendered again.

Otherwise, I don't see any solution apart from removing caching.

[jonbullock]

Sounds like a reasonable option to me. Oh and thanks for removing the license headers!

[melix]

Ok, I made the change, plus custom document types are now directly available from templates. For example, if you have a custom document type named foo, then foos in a template references the list of documents of type foo.

[glaforge]

What's the status of this PR?
Any plans for new releases including that PR?

[jonbullock]

I'm aiming to get the v2.2.1 release out this weekend then this PR along with #67 will be included in the next release which is scheduled to be v2.3.0, ideally as soon as possible.

[melix]

I am wondering how I should proceed, because master has changed a lot since this PR. In particular, mardown rendering engine has changed, which directly conflicts with the changes I made for parser modularization (#67).

Maybe a branch for 2.3 would be a good idea, that would avoid PRs to stay open for too long and get outdated. You could then backport (cherry pick) changes that you want in master back in 2.3.

[mwanji]

@melix maybe it would be possible to split this up into several PRs, prioritise them and rework them on top of HEAD in priority order? That might not be less work, but it might make it easier for @jonbullock to merge in?

I see at least 3 different features:

• incremental rendering
• multiple template engines
• custom document types

Personally, I'm most interested in incremental rendering, which would go great with watching for changes, so maybe I could help extract it, if you decide to do that?

[melix]

Well, the problem is at the very beginning. For example, the switch to pegdown broke parsing modularization, because it doesn't use the rework, of course. I don't want to redo the job multiple times, so I'd prefer doing a merge at some point.

[melix]

Rebased onto master

[jonbullock]

Thanks again.