-
Notifications
You must be signed in to change notification settings - Fork 327
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
Adds publisher option to jbake #113
base: master
Are you sure you want to change the base?
Conversation
… system properties. In order of precedence first environment vars, if not system environment and finally properties files.
This is a very nice feature, however sometimes the github branch can be something else than "gh-pages" . For instance it can be the "master" branch for a site like jbake-org.github.io . This PR has the "gh-pages" branch hardcoded, can you make it more configurable to address non "gh-pages" branches ? |
Yes this is true, but I am not sure (of course maybe I am wrong) that this is the kind of scenario that one user of jbake will use in most of situations. For example I have always seen that people have the master branch for the sources and the gh-pages for the autogenerated pages, because jbake autogenerate pages from sources, it seems logical that master branch will be the one where you will save your sources, and then the published branch where you render and serve the rendered pages. With the approach you are mention it seems that the sources are not saved so you use github as only web page server, which of course it is still valid. The good news is that this pull request not only contains the github (gh-pages) publisher but also an spi so everyone can implement its own publisher. So what you are explaining it is still possible for jbake, but I suggest that because we have an spi, instead of making publishers huge with different options (which some of them a deep impact on the implementation), create another publisher which can be called WDYT? |
Maybe, if user didn't configure his branch's properties "GithubPublisher" will use default strategy? |
Yes it is a possibility but if for example 80% of users want to release to gh-pages then you are forcing them to set branch name every time, maybe an special parameter Can be used Enviat des del meu iPhone El 25/05/2014, a les 12.33, volyihin notifications@github.com va escriure:
|
I mean if user will specify custom parameters - use their, if not - release to gh-pages(default parameters, hardcoded) |
Well both approaches have their pros and cons WDYT Johnattan? Enviat des del meu iPhone El 25/05/2014, a les 13.32, volyihin notifications@github.com va escriure:
|
I am using mainly jbake for what GitHub calls "user or organization" site and in this configuration, the master branch is used (unless it can be configured but I did not find the option). For "project" site, the "gh-pages" branch is used. For instance https://github.com/crashub/crashub.github.com It makes sense to address both use case, and have "gh-pages" to be the default. The maven plugin then could expose this option somehow. |
First off, thanks for the contribution Alex, great work! Please correct me if I'm wrong here as I've only reviewed the code online so far, but the constants in GithubPublisher could be defined via the configuration system but provide a default either through the default.properties file or even in the class itself in a similar way to here: This would enable the feature to just work out of the box for the 80% of users while still allowing the 20% of users to customise as they see fit. |
Hello, the problem is a bit complicated to explain but I will try. Github acts as a web server in two cases:
In both cases the project should be a git project so where is the problem. In jbake you have content, configuration, templates directories which can So what's happening with organization? It is not as easy as passing to the So passing as argument the branch name is has not much sense because Github So arribed at this point we can consider two approaches: First one is modify current publisher to something like: if(projectSite) { code to project site } else { But I think (and this is the style of programming) that classes should be Of course I am also thinking about WarPublisher, FtpPublisher, ... but it And obviously I have in mind create a plugin extensions for jBake as well, WDYT? 2014-05-26 23:30 GMT+02:00 Jonathan Bullock notifications@github.com:
+----------------------------------------------------------+ |
Thanks for explaining that Alex, I haven't used GitHub Pages yet myself. Since you've started the work to be able to add multiple Publishers, the support of User/Org Pages should be straight forward to implement in another class as you've suggested. |
Personally, I'd rather JBake not add publishing modules. I'm using the Gradle Github Publisher and it seems to me that it makes more sense to use your build tool of choice (e.g. Gradle, Maven, etc) to do the publishing step. I think there will be a greater selection of higher-quality choices that way and JBake can stay focused on core functionality. |
I agree with @msgilligan. I too use the Gradle Github Publisher. Adding publishing capabilities to jbake might make it overextend its responsibilities. The advantage of having it inside jbake is that any build tool could extend it with custom publishers. OTOH jbake is a site rendering tool (so far). I feel it for the maven users because the gradle plugin ecosystem is much more fun 😏 |
Thanks for the comments guys. I'm torn about adding this feature, which is why it's been pushed back to v3.0.0, for users who use build systems it does overlap existing functionality available. However, for users who prefer the CLI it would be beneficial. What if this was provided by a plugin/extension instead? Would allow JBake to stay focused on core functionality and this would not then become a consideration in any future development... |
Pluggable publishing extensions sound like a good compromise to me 😏 |
With this pull request jbake users can create their own publishers modules so after a site is baked can be published automatically.
Currently a Github publisher has been implemented but users can implement their own by using the jbake spi.
Also JDK has been updated to Java 7 to be able to use Java IO features developed on that version of java.