I'm trying to package compass/sass into a self-contained jar so that I can use compass without installing jruby.
I installed jruby and warbler on a Windows7 machine, running Java 1.6.0_37
I created a folder, named it jrcompass, then installed compass into it, i.e.
jruby -S gem install compass -i .
then I ran in it:
jruby -S warble
which created a file named jrcompass.jar of about ~20MB in size. so far so good.
problem is that when I try to execute the jar I get an error message (below). it seemed from the error that jruby.home was not set, so I passed it as a property in the command line and that worked, but it defeats the purpose of having a self-contained jar.
if I try to pass . as jruby.home then I get an error that it can't find rubygems
any help would be appreciated. TIA.
C:\Apps\test\jrcompass>java -jar jrcompass.jar
Gem::LoadError: Could not find compass (>= 0) amongst [rake-0.9.2.2]
to_specs at jar:file:/C:/Users/Admin/AppData/Local/Temp/jruby9093955264697226808extract/jruby-stdlib-1.7.1.jar!/META-INF/jruby.home/lib/ruby/shared/rubygems/dependency.rb:247
to_spec at jar:file:/C:/Users/Admin/AppData/Local/Temp/jruby9093955264697226808extract/jruby-stdlib-1.7.1.jar!/META-INF/jruby.home/lib/ruby/shared/rubygems/dependency.rb:256
gem at jar:file:/C:/Users/Admin/AppData/Local/Temp/jruby9093955264697226808extract/jruby-stdlib-1.7.1.jar!/META-INF/jruby.home/lib/ruby/shared/rubygems.rb:1231
(root) at file:/C:/Apps/test/jrcompass/jrcompass.jar!/jrcompass/bin/compass:22
load at org/jruby/RubyKernel.java:1046
(root) at file:/C:/Apps/test/jrcompass/jrcompass.jar!/META-INF/main.rb:1
require at org/jruby/RubyKernel.java:1027
(root) at file:/C:/Apps/test/jrcompass/jrcompass.jar!/META-INF/main.rb:1
(root) at jar:file:/C:/Users/Admin/AppData/Local/Temp/jruby9093955264697226808extract/jruby-stdlib-1.7.1.jar!/META-INF/jruby.home/lib/ruby/shared/rubygems/custom_require.rb:1
Related
VSCode, Java 11 JavaFX 18.0.2
I am trying to package my code up for distribution as a desktop app. In my case I want a fully self-contained app because of my target user's profile.
I have been through Jenkov add the Oracle docs here and here which suggest I need ant-javafx.jar. That jar file seems to have been dropped from the standard Java SDK some time around Java 7 and put into the regular JavaFX install lib folder.
It's not there in the build I have.
JavaFX seems to have gone to openjfx.io and nowhere in there can I see support for the ant packaging jar. In fact I see openjfx as a retrograde step as they are increasingly forcing everyone into paid plans (try going round and round the loop of downloading anything that doesn't require an LTS payment).
I have a suspicion that there is some silent assumption that everyone will use something from maven or gradle, and maybe the packaging tools are buried away in one of those build tools. For historical reasons I don't use either and it should be possible to do this packaging without one of them.
So where do I get the JavaFX Ant build tasks from without having to pay someone?
I have found that the following works as an alternative with Java 19 and OpenJFX 19. I use the maven-dependency-plugin to copy all the dependency jars (excluding JavaFX, which I use as modules from a "full" JDK [one that includes JavaFX)] into the target/lib directory.
#!/bin/bash
set -o errexit
set -o noclobber
set -o xtrace
# find dependency modules of required modules
DEP_MODS=$(jdeps -quiet --class-path "target/lib/*" --add-modules java.base,java.logging,java.sql,javafx.controls,javafx.fxml --multi-release base --ignore-missing-deps --print-module-deps target/myapp-4.0-beta.jar)
# create a modular runtime image
jlink --compress=1 --no-header-files --no-man-pages --add-modules "java.logging,java.sql,javafx.controls,javafx.fxml,$DEP_MODS" --output target/myapp-4.0-beta
# Example of running it out of the runtime image
# TEST target/myapp-4.0-beta/bin/java -cp "../../myapp-4.0-beta.jar:../../lib/*" org.myapp.App
# symlink to the artifact jar from the lib directory
$(cd target/lib && ln -s ../myapp-4.0-beta.jar)
# use the lib directory and modular runtime image as input to jpackage
jpackage --input target/lib --runtime-image target/myapp-4.0-beta --main-jar myapp-4.0-beta.jar --main-class org.myapp.App --type app-image --app-version 4.0 --name app --dest target/dist/bundle --mac-entitlements src/dist/mac/entitlements.plist
I am having problems compiling SQLite for use with Nodewebkit. After research, it seems that I am having wrong versions of the programs. So I have:
- Node
- NW
- SQLite
Apparently there must be certain version of each of the mentioned programs to make it work.
What versions of the programs I must have, so I can run this command:
npm install sqlite3 --build-from-source --runtime=node-webkit --target_arch=ia32 --target=0.12.3
This link suggests I should have NW version 0.8.x. But I cant find it for download. Or maybe that is not the problem at all...
I build on Mac using node-webkit v0.12.3 using the following commands:
sudo npm install nw-gyp -g
npm install sqlite3 --build-from-source --runtime=node-webkit --target_arch=ia32 --target=0.12.3
First, make sure you installed nw-gyp globally. Then, run the command either in the directory containing node-webkit executables (nwjs), or in a subfolder of that folder.
Running the command should then create a node_modules folder in the same directory as the binaries, containing the sqlite3 module.
From my previous question, I know that JavaFX is not supported in RedHat 5.8 meaning, even when I have Java 8 (jdk1.8.0_05) installed on my Linux, a JAR file created in win7 can't be executed via java -jar helloworld.jar. Does that mean there is NO way to run JavaFX jars on this machine?
The problem with running JavaFX applications on RHEL5 is the version of glib that comes with that OS is not new enough. The trick, then, is to provide a newer version of that library and all of the other libraries that depend on it to the JRE. The next hurdle is that RHEL5 shared library loader won't load those libraries. You have to use a compatible loader. But the JVM has the path to the loader hard-coded in the executable! So you need a separate JVM with a custom loader path patched in. Roughly, the steps to get this working are...
Unpack the following packages from RHEL6:
glib2
libffi
glibc
glibc-common
zlib
gtk2
pango
cairo
pixman
Put all of the shared libraries from those packages in a directory on your RHEL5 system. Let's call it /YOUR-ALIEN-RHEL6-LIBS-PATH.
Unpack another copy of a JRE to, say, /YOUR-ALIEN-JVM-PATH.
Use patchelf to point the JVM executable to the new loader.
./usr/bin/patchelf --set-interpreter /YOUR-ALIEN-RHEL6-LIBS-PATH/lib/amd64/ld-linux-x86-64.so.2 /YOUR-ALIEN-JVM-PATH/jre1.8.0_25/bin/java
Run the application after setting LD_LIBRARY_PATH=/YOUR-ALIEN-RHEL6-LIBS-PATH/lib/amd64:/YOUR-ALIEN-RHEL6-LIBS-PATH/lib/amd64/jli
Although it is not pretty, I have successfully run JavaFX applications on RHEL5 using this method. Having said that, I highly recommend just upgrading your OS if it is even remotely feasible.
Note this builds upon the existing answer from James with more concrete detail
Obtain RPMs from a RedHat 6.x, e.g. http://vault.centos.org/6.2/os/i386/Packages. Copy into directory rpms/
cairo-1.8.8-3.1.el6.i686.rpm
glib2-2.22.5-6.el6.i686.rpm
glibc-2.12-1.47.el6.i686.rpm
glibc-common-2.12-1.47.el6.i686.rpm
gtk2-2.18.9-6.el6.centos.i686.rpm
libffi-3.0.5-3.2.el6.i686.rpm
libXcomposite-0.4.1-2.el6.i686.rpm <== not mentioned in other answer
pango-1.28.1-3.el6_0.centos.5.i686.rpm
pixman-0.18.4-1.el6_0.1.i686.rpm
zlib-1.2.3-27.el6.i686.rpm
libXdamage-1.1.2-1.el6.i686.rpm <== not mentioned in other answer
Extract all the contents from the RPMs into separate directory. Use rpm2cpio and xzcat. xzcat can be installed from these RPMs if necessary [xz, xz-libs, xz-lzma-compat]
mkdir redhat-6u2-libs
cd redhat-6u2-libs/
ls -1 rpms/* | xargs -i{} bash -c "rpm2cpio {} | xzcat | cpio -idmv"
Obtain copy of patchelf. I built from source as couldn't find a Redhat 5 RPM. Only requires dependent RPMs [gcc, gcc-c++, glibc-devel, kernel-headers, libstdc++-devel]
wget https://nixos.org/releases/patchelf/patchelf-0.9/patchelf-0.9.tar.bz2
tar xjf patchelf-0.9.tar.bz2
cd patchelf-0.9
./configure --prefix /tmp/patchelf
make install
Use patchelf to set location of redhat 6u2 loader (aka interpreter)
/tmp/patchelf/bin/patchelf --set-interpreter ~/redhat-6u2-libs/lib/ld-linux.so.2 jdk1.8.0_40/bin/java
Set LD_LIBRARY_PATH, this needs to have both /usr/lib and /lib, otherwise you get a segfault.
export LD_LIBRARY_PATH=/home/user/redhat-6u2-libs/usr/lib:/home/user/redhat-6u2-libs/lib
(Note that any other applications run after LD_LIBRARY_PATH is set other than java which has had its interpreter location corrected will segfault.)
Now run java app...
./jdk1.8.0_40/bin/java -cp etc...
Happy days
qmake: could not find a Qt installation of ''
This thread was not of any help to me. qmake: could not find a Qt installation of ''.
How can I get qmake to recognize where the Qt folder is?
Right now it is installed in /opt/Qt5.1.0.
Have you installed the qt5-default ? You need to do this in addition to running the Qt supplier .run file.
sudo apt-get install qt5-default
This message shown by qtchooser app.
To setup it properly, you should make conf files in /etc/xdg/qtchooser/
for example:
$ ls -1 /etc/xdg/qtchooser/
default.conf
qt-4.8.5.conf
qt-5.1.0.conf
each file has two lines: path to bin, path to lib:
$ cat /etc/xdg/qtchooser/default.conf
/opt/Qt/4.8.5/bin
/opt/Qt/4.8.5/lib
additional info: man qtchooser
The solution for me on this problem was to specify the QT version, as this message was being generated by /usr/bin/qtchooser
So in my case, it was QT4 I was trying to use, and running:
qmake
generated the error (could not find a Qt installation of '')
qmake -qt=qt4
fixed that error though. In my case, it was a Ruby Gem trying to compile with qmake, so I couldn't get it to pass in that extra command line argument, so I instead added this to my profile
export QT_SELECT=qt4
And now QT4 runs just fine on my Ubuntu system.
For me the symlink to default.conf was missing in /usr/share/qtchooser. It wasn't enough to put it into /etc/xdg/qtchooser.
I am trying to use compass with Drupal 7, Basic theme and Compass module on my local hosting on Windows. It is already installed on my computer. Should i install it to my local webserver again, how can i know the path of existing Compass exutable?
Some more details would help get to the root of the problem:
Are you running compass from the command line, or using a GUI utility?
Did you install compass via gem install compass ?
What version of Windows are you running?
If you have properly installed ruby and compass, you should be able to cd into your drupal theme's directory and run compass watch to compile.
You can use the where command from the windows command prompt (where compass or, if that doesn't work where ruby) which will search your current directory and $PATH. If you cannot find compass, then you may need to reinstall compass/ruby.
Hope that helps!