Is there a way for an organization that uses a series of Jekyll blogs (ideally running on Github Pages) that are related in that they'd have the same header, style, and footer, but manage separate contents to work together? The blogs are necessarily separate because the idea is that each should be able to stand on its own, but should still work nicely together. Specifically the concern is local development.
To see the specific use case, check out Open Source Design, and how it plays out on the actual website. Right now changing a style for the jobs subdirectory involves copying over the CSS, tweaking it, and moving it back to the the website.
Something I've seen work for rails apps and might be an idea is looking into setting up Anvil to work with Jekyll instances to power all the instances? Is there anything out there that has tried that?
organisation.github.io is the repository that manage organization wide styles in organization.github.io/css/main.css.
Any layout in a repository at github.com/organization/project will use the central css at organization.github.io/css/main.css. Any specific css can be in the repository itself.
This is also true for javascript files with no fear of cors.
The only problem can be for local development and the need to link css with an absolute path to online resources.
Note that Open source design is already doing this, pointing all pages to http://opensourcedesign.net/css/main.css or /css/main.css which is the same file.
I would suggest that what are you trying to do is outside the scope of a static site generator. You need to configure assets based on the environment in which they will be used. You need a build system like grunt, gulp, or even Rake. The build system can pull assets from a single source folder, pre-process them as needed (changing asset URLs as needed), and move them to various output directories for each of your blogs.
Or you could try to put your assets in one repo and make each of your other repos depend on the assets repo as as submodule. Then you can update the assets independently of the contents.
Related
I'm interested in collecting some of my lecture notes and hosting them on my personal website to share with other students and for my own reference. Essentially, I would like the notes for each lecture to exist at {me}.github.io/notes/{class}/lecture_{number}.html
I started by creating a GitHub repository for each class, and setting up a corresponding project page. However, this places each class at the base of my website, e.g. {me}.github.io/{class}/notes/, and I'd prefer to have a single reference page that organizes my classes, as above.
I also tried using Jekyll collections to handle this, but it seems like you can't create nested collections. I found this related question for a pseudo-workaround, but it requires me to store all of my notes in a single directory, which I'm reluctant to do.
Is it possible to accomplish what I'm hoping for cleanly, or do I have to hard-code it all in or use the workaround above? Thanks!
You could probably achieve something like this with collections, but there is a much easier way.
First, you'll need to create a repository called 'notes', and turn on GitHub Pages for it (as you've already done). Add baseurl: "/notes" to _config.yml.
Your site will now be served at {me}.github.io/notes/.
Then, in that repository, create a folder for each class. And in each class folder, create a markdown file for each lecture. E.g. lecture_1.md.
Finally, turn off Jekyll's pretty permalinks by adding this to _config.yml:
permalink: none
That should give you the URL structure you're after. Your notes for lecture 1 would be at {me}.github.io/notes/{class}/lecture_1.html.
I have a Phonegap project that contains a lot of html-files, javascript files, css-files and images.
When I build the app I want to keep it as small as possible, so I want to exclude all files that are NOT used in the html-files. For example some images in the 'img' directory might not be used in the app.
Somehow I need to make a build-script that searches in every html and css file for other files that are included. Of course the problem is that in each file url's can be relative or absolute.
Is this something that can be automated (maybe with ant?) , or does everybody always pick all necessary files by hand for deployment?
You can use grunt.js
In one word: automation. The less work you have to do when performing
repetitive tasks like minification, compilation, unit testing,
linting, etc, the easier your job becomes.
Basically you can minify and merge all your css in one file as well as all js in one file. At the same time you can exclude files for build process. You can google for example code. I. E.
https://coderwall.com/p/e0jxea or https://github.com/centralway/grunt-phonegap-build (phonegap project grunt based)
I have two pieces of somewhat unrelated source that I want to turn into one "site" using Jekyll. But they are in two directories. Let's say PROJECT/site/ has the homepage and copy and so forth, and PROJECT/clientlib/ has a bunch of libraries. I'd like, for example, PROJECT/site/index.md to become /index.html and PROJECT/clientlib/foo.js to become /clientlib/foo.js
This is an open source project so I'd really like to avoid fooling around with symlinks or submodules that might make it harder for someone to check the project out and start using it. And I want to be able to use the Jekyll dev server, without doing fixup on the generated files.
Is there a way to configure (or hack) Jekyll to get the layout I'm hoping for?
I just finished publishing a custom gem that accomplishes this. It lets you specify a shared_dir that can be used between multiple Jekyll configurations for a common base:
https://github.com/sumdog/jekyll-multisite
You can give them the same destination path in your _config.yaml file (in place of the default _site, see https://github.com/mojombo/jekyll/wiki/Configuration
e.g.
destination: ../_site
but you will overwrite filenames, etc if they are duplicated between the two.
I'm working on a project with two other developers that's built on FireBreath. So far, I've been able to get things working perfectly on my machine, but we need to coordinate our development via Mercurial. So I pushed my files to the repository and thought all was well.
Unfortunately, that doesn't work.
The various .vcproj files that make up the solution all contain hard-coded references to my local file system. This works fine for me, because I'm not moving the project around. But when you try to build the solution on another machine with a different file structure (different drive letter, different folder location, etc.) everything breaks.
I used FireBreath's standard project generation script (Python) and then the Visual Studio CMake script (prep2008.cmd) to generate the solution files. What can I do to tweak things so that other developers can use the same code base?
If your developers are not using the same build/make/project files, this could quickly become a maintenance nightmare. So you should definitively all use the same .vcproj files. (An exception to this would be if the project files were generated from some other files. In that case treat those other files in the way described above.)
there's two ways to deal with the problem of differing setups on different machines. One is to make all paths relative to the project's path. The other is to use environment variables to refer to files/tools/libraries/whatever. IME it's best to use relative paths for everything that can be checked out with the project, and use environment variables for the rest. Add a script that checks for the existence of all necessary environment variable, pointing out the meaning of any missing ones, and run this as a build prerequisite, so whoever tries to get a new build machine up and running gets hints at what to do.
To make sure that everyone caught the updated comments from sbi's answer, let me give you the "definitive" answer from the FireBreath devs.
Your build directory is disposable; you should never share .vcproj files. Instead, you should regenerate your build/ directory any time you change the project and on each new computer, just like any project that uses CMake.
For more information, see http://colonelpanic.net/2010/11/firebreath-tips-working-with-source-control/
For reference, I am the primary author of FireBreath and I wrote the article.
I'm not familiar with FireBreath, but you need to make the references relative, and then recreate that relative structure on every machine. That is, if your project sits in "c:\myprojects\thisproject" and has an additional include directory "c:\mydir\mylib\include", then the latter path needs to be replaced with "....\mydir\mylib\include".
EDIT: I rewrote my anyswer to make it clearer. When I got you correctly, your problem is that FireBreath generates those .vcproj files with absolute paths in it, and you want to use this .vcproj files on a different developer machine.
I see 3 options:
Live with it. That means, make sure, every team member has the same file structure / view to the file system, tools installed in the same place.
Ask the authors of FireBreath to change their .vcproj generator to allow relative paths, use of environment variables etc.
If 1 or 2 does not work, write a program or script for changing the absolute path to relatives in those .vcproj files. Run this script whenever you have to regenerate your FireBreath project.
What you should not do due to the FireBreath FAQ: don't change the .vcproj manually, those changes will be lost next time the project is regenerated.
EDIT: seems that "option 4." turned out to be the best solution: generating those .vcproj files for each developer individually. Hope my suggestions were helpful, either.
I want to give credit to all open source libraries we use in our (commercial) application. I thought of showing a HTML page in our about dialog. Our build process uses ant and the third party libs are committed in svn.
What do you think is the best way of generating the HTML-Page?
Hard code the HTML-Page?
Switch dependency-management to apache-ivy and write some ant task to generate the html
Use maven-ant-tasks and write some ant task to generate the HTML
Use maven only to handle the dependencies and the HTML once, download them and commit them. The rest is done by the unchanged ant-scripts
Switch to maven2 (Hey boss, I want to switch to maven, in 1 month the build maybe work again...)
...
What elements should the about-dialog show?
Library name
Version
License
Author
Homepage
Changes made with link to source archive
...
Is there some best-practise-advice? Some good examples (applications having a nice about-dialog showing the dependencies)?
There are two different things you need to consider.
First, you may need to identify the licenses of the third-party code. This is often down with a THIRDPARTYLICENSE file. Sun Microsystems does this a lot. Look in the install directory for OpenOffice.org, for example. There are examples of .txt and .html versions of such files around.
Secondly, you may want to identify your dependencies in the About box in a brief way (and also refer to the file of license information). I would make sure the versions appear in the About box. One thing people want to quickly check for is an indication of whether the copy of your code they have needs to be replaced or updated because one of your library dependencies has a recently-disclosed bug or security vulnerability.
So I guess the other thing you want to include in the about box is a way for people to find your support site and any notices of importance to users of the particular version (whether or not you have a provision in your app for checking on-line for updates).
Ant task seems to be the best way. We do a similar thing in one of our projects. All the open source libraries are present in a specified folder. An Ant task reads the manifest of these libraries, versions and so on and generates an HTML, copies into another specified folder from where it is picked up by the web container.
Generating the page with each build would be wasteful if the libraries are not going to change often. Library versions may change, but the actual libraries don't. Easier to just create a HTML page would be the easiest way out, but that's one more maintenance head ache. Generate it once and include it with the package. The script can always be run again in case some changes are being made to the libraries (updating versions, adding new libraries).