split jbake into core and application

[ieugen]

Hello,

I've posted an email on the user mailing list about some improvements. Right now thare are a lot initializations that can be skipped and are not. The code could make use of dependency injection to make the code easy to reuse.

It is also my opinion that jbake currently does way more than it should in a single project"

• render pages
• start a webserver
• parse command line parameters

I think this should not be the case. I would split the code in multiple modules:

• jbake-core (or a similar name ) module that does rendering

• a jbake-cli (or jbakery) that uses the core and does command line parsing, web server and other stuff

  Proof of concept project: https://github.com/netdava/jbakery

[danielkocot]

Hello @ieugen,

I share your opinion about multiple modules for jbake and I really like your poc :-).

[ieugen]

Thanks @danielgrycman .

I just added watch functionality to 0.0.4 ( you net to specify --destination outside --source or you get an infinie cycle atm) . I'm working on adding ant style path matchers to ignore paths and files inside the work tree.

I have alot of ideas but a lot of them need jbake refactoring. Right now I'm still waiting for answers but I am considering forking the project. I would very much like to avoid that and that's why I'm coming with issues and questions.

[jonbullock]

Just posted a reply to your message on the users mailing list.

Watch mode has already been added to master: https://github.com/jbake-org/jbake/issues/253

The plan to split up the project into multiple modules is available here: https://github.com/jbake-org/jbake/issues/117 - are you interested in working on this?

If you want to start a discussion on the developers mailing list for your other ideas I can bring you up to speed with what is currently being worked on and by who?

[ieugen]

Hi,

Thanks for the reply. I agree that things should be discussed and this is how comunity will grow. Having that said, I did notice that those threads are 2 years old and jbake is still monolithic.

I think its time for action. My take from the discussions is:

• a split is desired and needed. there are different ideas on how to do it but let's start and see how it goes.
• migrating to Gradle would help with that

I also think we should make the development/contribution process more open so the project will grow. I say this because we are all too busy to contribute from time to time and it is desirable that the project moves forward regardless of our personal schedules.

I am a contributor to Apache Software Foundation, OPS4j, Debian Project and I know comunity is very important for an open source project.

I would suggest jbake took some practices/policies/processes from those comunities.

p.s. I would also like to have a chat (text or sound) with you @jonbullock to get to know eachother and the plans.

[ancho]

:+1: Thank you @ieugen for pushing the growing of the community forward. I'm looking forward to learn from your experience.

[danielkocot]

@ieugen You are right the contribution process should be more open. If not so we loose the chance of a growing community :-). I would like to take part in this process :-).

[jonbullock]

I realise there are multiple discussions going on in different places but for completeness sake I'll comment here:

@ieugen could you provide some examples on practices/policies/processes you have in mind? I'll also try to be on IRC a bit more over the coming week so we can get a chat started.

[jonbullock]

Linking this to the original issue #117

[ieugen]

@jonbullock There are no silver bullets since each project is unique. This should also be done gradually, as the need arises and we should split to get benefits, not just because we can.

The functionality that I see can be part of different modules right now is:

• core - the rendering engine and all the domain logic of taking content and templates and rendering them to HTML
• application - the CLI and web server that uses the core to drive the rendering process by exposing the core functionality to the user.

By separating them like this we allow people to embed jbake-core into their own applications, without dragging a lot of dependencies (like jetty and CLI parsing libs, etc). Of course we could split core further into rendering plugins and such, but at the moment this should be enough. That should be done as a later step in my opinion.

Am I making sense :)?

[jonbullock]

@ieugen On the separation into sub modules, yeah absolutely. :)