Is there a recommended workaround for warbler not supporting the path options in a Gemfile?
Is there a fundamental reason why path is not supported (and I couldn't just implement it)?
The path option is not portable. Bundler expects to be able to find the code at that path, which sort of defeats the purpose of a self-contained war file.
A workaround would be to run "git init; git commit -a" in the directory of the path-based gem and treat it like a git-based gem instead. Then Bundler can check out a copy of the code and Warbler can store the copy in the war file.
I (unfortunately) can't post code for this (yet...), but I have successfully done the following:
Hack warbler (basically replace the whole bundler gem packaging code) to copy gems specified with :path into vendor/gems (normal gem location is gems/gems). This copying was done nearly identically to how warbler copies gems from a :git specification.
Monkeypatch bundler so when it loads a Gemfile with :path specs, they are rewritten to point into vendor/gems.
It's not pretty, but I have been very happy with this solution.
Another option I have seen is to create a vendor/gems directory which contains symlinks to all the gems that use :path in the Gemfile. Warbler will complain about not supporting :path gems, but they will be copied in the WAR file via the symlinks. I do not like this solution because you've got to maintain the :path in the Gemfile and the symlink, but it is easier to implement than the above.
Also, I agree with Nick Siger that supporting :path as-is (without any of the above hacks) does defeat the purpose of a self-contained WAR file, but a self-contained WAR file is not always desirable. There are tradeoffs to a not-self-contained WAR file of course, but one advantage is being smaller in size, quicker to copy, unzip, etc. Of course, supporting this would require changes to JRuby-Rack as well as to Warbler.
Related
Lately I've gotten into Jekyll for building documentation sites and hosting them on Github Pages. I understand Github Pages has a very limited list of what is allowed plugin wise. While doing some vulnerability testing I found out the file Gemfile.lock is vulnerable to XML External Entity (XXE) Injection.
In my research I've read:
Should Gemfile.lock be included in .gitignore?
A Gem's Gemfile.lock should NOT be in source control.
Setting up your GitHub Pages site locally with Jekyll
After reading the accepted answer of:
Assuming you're not writing a rubygem, Gemfile.lock should be in your repository. It's used as a snapshot of all your required gems and their dependencies. This way bundler doesn't have to recalculate all the gem dependencies each time you deploy, etc.
but I have no control over the Jekyll site. Please correct me if I'm understanding the process but Github Pages builds the site and if the Gemfile.lock is for development of Gems and that isn't something I can control it's ok to remove the file and add to the .gitignore?
GitHub Pages doesn't look for a Gemfile.lock file nor the Gemfile itself.
All it needs is a proper config file to load gems / plugins.
I just noticed that jekyll has all it needs installed locally, but a remote-theme is fetched every time jekyll is started.
I've also seen that people proposed a cache extension which hasn't been merged yet.
So I wonder if it is possible to just clone the remote theme to a certain folder?
ok, found the solution:
most themes are available also as ruby gems. So instead of specifying a remote-theme, I add the corresponding gem to Gemfile
gem "minimal-mistakes-jekyll"
and then reference it in the _config.yml
theme: minimal-mistakes-jekyll
In my rather unique application needs, I've had to make a patch to JRuby-1.7.26. However, I've learned that Warbler (that uses jruby-jars) embeds it's own copy of JRuby into my lib/ directory. How can I configure either Warbler or jruby-jars to consider my patch when it compiles JRuby?
you need to build a custom version of jruby-jars gem (from the JRuby source)
and then specify that version to be used in the Gemfile :
gem 'jruby-jars', '1.7.26.PATCH', require: false
I think I'm just at the finish line for installing jekyll on windows, It's connecting fine, but I'm getting an error message:
Liquid exception: No such file or directory - python C:/Ruby193/lib/ruby/ms/1.9.1/gems/pygments.rb-0.6.3/lib/pygments/mentos.py in _posts/2015-06-09-welcome-to-jekyll.markdown<-[0m done.
Please add the following to your Gemfile to avoid polling for changes: gem 'wdm','>=0.1.0' if Gem.win_platform
I'm not sure what messages I can ignore and what I need to fix. What do you guys think?
If adding this to my gemfile is as simple as entering a cmd prompt, what do I need to enter to install it?
This was an issue that was addressed by me by another question a few days ago.This is the original question and my answer.
Basically the issue here is that you need to install Python to use Jekyll on Windows because the code highlighter Pygments is written in Python, hence requires Python to function. Pygments is alsothe default code highlighter currently. In the future versions of Jekyll will use the Rouge highlighter, which is written completely in Ruby. This issue is tracked on GitHub.
To solve your current problem, you just need to install Python 2.x, which the official linked guide from the Jekyll documentation provides very clear instructions there. You will also need to install pip. I have also included alternatives in the other SO answer I have given, so I will just provide you the link to it to reduce duplicate information and copy-paste.
Once you have Python 2.x and pip set up, and install pygments, your Jekyll install should be up and running with the site template!
Regarding the Gemfile
A summary of what a Gemfile is: A file that lists all the required Ruby gems for a particular program. For example, you wrote a ruby program that depends on 10 other gems, rather than ask the user of your new gem to go download the previous 10 gems, and then later wrestle with outdated gem issues, a Gemfile is used to keep track of what gems are needed and version. The Gemfile is used by Bundler, which is also a gem that automatically keeps track of what gems you need. In the case of Jekyll, you can use a Gemfile to dictate what you want added into your Jekyll install or removed. This is used by GitHub to keep local versions of Jekyll and other gems updated with the version used by Github Pages.
As for that notification, all you would need to do to avoid polling for changes is:
Open notepad or text editor of choice.
Add this line: gem 'wdm','>=0.1.0' if Gem.win_platform, just that line of text. You can later add gems by typing in gem 'nameOfGem in a separate line.
Save the file as Gemfile in your Jekyll site's folder. Notice that there is not .txt extension, which you can create a file with no extension in notepad by choosing 'All Files' instead of '.txt' under 'Save As'. Or, you could just edit the file extension to remove the .txt.
Install bundler by executing gem install bundler.
Run bundle install to update the gems. If you're using GitHub, add the Gemfile and the newly generated Gemfile.lock into git.
The current Trinidad gem depends on jruby-rack 1.1.0 which has some errors being displayed in my development log for every single one of my assets
/Users/bijan/.rvm/gems/jruby-1.7.3/gems/rack-1.4.5/lib/rack/utils.rb:399 warning: multiple values for a block parameter (2 for 1)
This is an issue that has apparently been resolved in the current jruby-rack (1.2) master branch and I'd like to make trinidad depend on this.
Is there a way to do this from within my Gemfile? Or another simpler solution than forking the Trinidad gem and specifying a different version of jruby-rack (and wishing it works since it may not).
TL;DR - not really. You'll need to build one or both projects or get some help from the jruby-rack team by way of a release. See bottom for build steps.
The current Trinidad versions (1.4.4 and 1.4.5B1 prerelease) use jruby-rack with optimistic versioning (>= 1.1.10 and >= 1.1.13, respectively), so any dependency that satisfies this (say, 1.2.0) would take precedence without touching Trinidad.
Unfortunately, because of how the JAR is packaged, a git: or github: dependency will not work. You would need to build the gem yourself. This is not too bad -- you really just need Maven beyond a working JDK/JRuby setup.
Once jruby-rack is built/released with the changes, will be able to specify a workable version in your Gemfile (assuming it gets versioned 1.2.0):
gem 'jruby-rack', '~> 1.2.0'
gem 'trinidad'
Maybe the jruby-rack team could backport this specific change to the 1.1.13 maintenance line and push a 1.1.13.2 release if it doesn't introduce incompatibility. Or they may be willing to do a prerelease from master.
I haven't tested that things work properly for assets, but building and specifying the local version was relatively easy:
# Assuming mvn is on the path, JRuby is active, and you
# have gem install permissions:
git clone https://github.com/jruby/jruby-rack.git
cd jruby-rack
bundle install
bundle exec rake clean gem SKIP_SPECS=true
gem install --local target/jruby-rack-1.2.0.SNAPSHOT.gem
After this, you can use gem 'jruby-rack', '~> 1.2.0.SNAPSHOT' in your Gemfile to satisfy Trinidad and test whether your problem is resolved.