Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

split jbake into core and application #274

Open
ieugen opened this issue Mar 27, 2016 · 10 comments
Open

split jbake into core and application #274

ieugen opened this issue Mar 27, 2016 · 10 comments
Milestone

Comments

@ieugen
Copy link

ieugen commented Mar 27, 2016

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

@ieugen ieugen changed the title jbakery - faster rebuilds and web console split jbake into core and application Mar 27, 2016
@danielkocot
Copy link
Contributor

Hello @ieugen,

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

@ieugen
Copy link
Author

ieugen commented Mar 27, 2016

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
Copy link
Member

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

Watch mode has already been added to master: #253

The plan to split up the project into multiple modules is available here: #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
Copy link
Author

ieugen commented Mar 28, 2016

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
Copy link
Member

ancho commented Mar 28, 2016

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

@danielkocot
Copy link
Contributor

@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
Copy link
Member

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
Copy link
Member

Linking this to the original issue #117

@ieugen
Copy link
Author

ieugen commented Jun 6, 2016

@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
Copy link
Member

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants