Plugin bootstrap proof of concept

[mwanji]

Not really meant to be pulled, just an example how a plugin system could be bootstrapped:

• A plugin directory is created next to lib. JARs can be dropped in here.
• jbake script adds plugin to classpath (jbake.bat not modified and only tested on Ubuntu, not Mac).
• Plugins implement the JBakePlugin interface and declare themselves as a service for that interface.
• In Main, a ServiceLoader picks up all implementations of JBakePlugin and calls init on each one.

[rajmahendra]

Feel free to try https://github.com/rajmahendra/JBakeProject This is done in same approach what you have shared. The code now become old since i took but @jonbullock need to take a path from V3 to modularize the jbake project structure. The one i have has broken the core jbake project and created 4 sub projects.

[rajmahendra]

I see there are two approach we can design the Plugin

1. Bind plugin with the life-cycle of JBake
   In this approach we need to give the current progressing page/post to the plugin and get the processed content from the plugin and do the process.

Some use case are

• Adding dynamic comment features like Facebook,Discuss. Google+ comments to the post/page (based on plugin dependent header on jbake header, say commented=true etc)
• Spellcheck feature for the content

For above plugin need to get the current processing page/post and work basked on that. (My plugin is not yet ready in this)

1. Give the whole structure to the plugin and let it do
   In this approach JBake completed gives the full Crawl to the plugin so plugin will decide what it need to do. In this approach jBake cant take any control of all the work ....

Some use case are

• SiteMap
• Archive
• Authors page

I have dilemma between these two approach i feel if our plugin supports both its nice.

Also user some time have adding of the Templates also! this approach is too abstract but this is also a feature where the plugin developer have control of the current template also!

As i mentioned above that it uses a lifecycle.. we can even build a plugin based on lifecycle of jbake also! Event-driven plugin ! (Just a wild guess! )

[jonbullock]

Great work and discussions going on here everyone. I've not forgotten about this, once the internal modularisation is complete plugin support is the next big feature to add. :)

[melix]

Note that in #68 (which I'm already using in production), I already allow custom page types, with custom templates. This is done only by declaring a new page type in jbake.properties, by convention:

template.users.file=users.ftl

Then you can use the "users" type in any content page.

[rajmahendra]

@melix users! you mean people involved in a website as authors right ? i feel we can call it Author :)

[melix]

I chose users but I could have called my template bonobos, would work the same :)

[mwanji]

@rajmahendra

The one i have has broken the core jbake project and created 4 sub projects.

I went through your code. I saw the use of ServiceLoader, but how do the plugins actually get on the classpath (when JBake is used from the CLI, rather than embedded)?

Adding dynamic comment features like Facebook,Discuss. Google+ comments to the post/page (based on plugin dependent header on jbake header, say commented=true etc)

Wouldn't these kinds of social plugins need to be in a template, rather than in post metadata? So the template could contain ${social_comments_fb} for Facebook comments, for example, which would be replaced by the appropriate HTML/JS. This would require plugins to be able to add entries to the data model.

I don't understand the second set of usecases, as those seem to be handled just fine as templates? 2.2.1 even adds a sitemap template.

Have plugin usecases been discussed anywhere else?

[jonbullock]

Here's my original vision for plugins/extensions:

There will be a number of hook or extension points in the JBake API, each at various points along the processing pipeline. Such as content crawling & parsing (to include more content than just static files), pre-processing (allowing modification of content before format conversion say from Markdown to HTML), post-processing (allowing modification of the HTML to be rendered), rendering (allowing template engine related alterations), and asset processing (allowing minification of CSS & JS or conversion from LESS to CSS). Each of these points will have their own plugin interface to allow multiple types of plugins, so there can be multiple plugins for each extension point. What each plugin can do depends on the interface for that extension point in the processing pipeline, so at the content crawling and parsing stage the plugin can interact with the content store. At the asset processing stage the plugin will be passed each asset file and it's up to the plugin to decide whether to perform additional processing on the file or not.

I realise this is a proof of concept and slightly different to what I've just outlined however I can see having an init method potentially beneficial. I also like the idea of having a separate plugins folder.

Anyway I just wanted to get my vision out into the public so it can be discussed, changed, fixed or updated. All comments welcome!

I'll also knock up some diagram and post this to the dev mailing list too.