I'm maintaining a perl script which runs an automated install of our base server software. One of the new requirements is to install the Inline::Java module.
Our usual strategy of installing using Yum seems to fall down as there's no Inline::Java available in yum. I can't find an RPM release for it so can't install as an RPM. The only options seem to be installing through CPAN or shipping the tar and having a step which identifies the SDK location and runs 'perl Makefile.PL J2SDK=; make; make install'.
Instinctually I think that's a little shaky for an automated install, I've had problems with CPAN installs failing in the past and I don't really want to have to make on a live server, but I can't think of a better option.
The other option I considered was just shipping the .pm file, placing it in a user defined directory and using 'use lib' to define that as a location but due to the way Inline::Java works I don't think this is possible, it needs the location of the InlineJavaServer and such too.
Does anyone have a better solution or an opinion on which of the ones proposed above is the best?
You could build your own perl-Inline-Java package and put it in a private yum repository, or even contribute it to Fedora/EPEL.
Inline::Java will look for InlineJavaServer.jar and the other files it needs in the same location as the Inline/Java.pm file. Copying the whole distribution from the install directory on one machine and copying it to another machine (with the same architecture) isn't as crazy as it sounds. If you only have a few different systems (not all linux, 32 bit vs 64 bit, perl 5.6 vs perl 5.10, etc.), it is tractable to make a separate package for each system.
There is some install-time configuration in Inline::Java, including specifying the default Java installation to use. But this (and other default configurations) can always be overridden with environment variables like PERL_INLINE_JAVA_J2SDK (see the Inline::Java perldoc for the complete list). You could package Inline::Java with your own custom module, say,
MyCompany::InlineJavaConfig, that can set the appropriate environment variables before the Inline::Java module gets loaded in each script.
There's some other install-time configuration like whether to configure JNI and other native support. It might be a little dicier to copy the files that support these features from one machine to another. But I can't think of any reason off-hand that it wouldn't work.
Related
I'm writing some code that uses the Subversion (SVN) Java bindings (JavaHL) directly (where JavaHL comprises native libraries and a thin Java wrapper). On Linux (Ubuntu 12.04) this is no problem: package libsvn-java installs the native libraries and \usr\share\java\svn-javahl.jar, so i just reference the latter and away I go.
On Windows, I know of no such clean packaging of the pair (JAR + native libraries) together. I was aware that SlikSVN contains a JavaHL implementation, but installing that seems only to install the native libraries (which it does put on the PATH). Is there anything that gives a clean package of the two? (If SlikSVN does package the JAR, it's in no place I expect, and a search of the whole drive finds nothing...)
As a workaround, I built the JAR file manually (details below which may be useful for people). But it seems that the 'match' of Java wrapper and native libraries is very precise: when I built a JAR from later SVN source code (instead of that matching my exact SlikSVN SVN version) as a test, I got fatal errors in the native code (EXCEPTION_ACCESS_VIOLATION). Perhaps I was unlucky but, if it is pretty sensitive, I'll need to provide a JAR library for every potential version of SlikSVN (and thus SVN) that users might install (or restrict their SlikSVN choices, or have some prone-to-error auto-build process which would need them to install a JDK). All bad options :-(
Manual Workaround (Bad!)
I had SlikSVN 1.8.10: svn --version reports version 1.8.10-SlikSvn-1.8.10-X64.
So I got the Java wrapper source from the tagged SVN release. (You can also get it from the
main site's source downloads.)
svn export http://svn.apache.org/repos/asf/subversion/tags/1.8.10/subversion/bindings/javahl/src
Compiling this (there are no dependencies) into a JAR, and using that, worked fine with the SlikSVN native libraries.
P.S. I know that I could use SVNKit to avoid having to do this, but I'm doing this precisely so as not to rely on SVNKit for licensing reasons (plus the JavaHL API is fine and reasonably high-level anyway, and there are other reasons to prefer using the 'official' native JavaHL implementation).
The WANdisco binaries should have JavaHL in them.
http://www.wandisco.com/subversion/download
Been a while since I used them myself (don't typically use Windows). But WANdisco has tools that depend on JavaHL so I can't imagine the Windows binaries are missing JavaHL.
[Question author edit to complete detail]
You need to install the (Windows) Subversion client (not SmartSVN), and make sure you check the box to add it to the Windows PATH. This stores the 'paired' JAR in the install directory (along with the native libraries). However, WANDisco only provide a 32-bit install (see this forum post) so this won't work on 64-bit Windows. In addition, the JAR only includes the Apache versions of the API, which were added for Subversion 1.7. If you're using the legacy org.tigris.subversion.javahl package API for compatibility with pre-1.7 SVN clients, you still need to build the JAR manually.
I'm working on a program that utilizes Caprica's VLCJ Bindings.
This is fine and good for Windows and Mac, as I can just package the VLC Libraries for them in a zip file and output them to the user machine where appropriate.
The problem comes when I need to do this for Linux, because, dear god,
there are ELEVEN. SEPARATELY COMPILED. APPLICATIONS/LIBRARIES.
And some of them even have their own flavors. It's like the Baskin Robins of OS's (I knew there were a few but I've only really ever run Ubuntu so I was not prepared for this).
If I was a masochist I could totally make this work and end up with a gigantic jar with an absurdly huge number of zipped Linux libraries within it, but I really, reHEHEHEALLY do not want to do that.
So I figured that the best course of action to take would be to check if LibVLC is installed, and if it is, reference it directly, and if it isn't, install it at run time (before the library tries to load itself), or, heck, even at launch/install time for the Java program.
Is this possible? I know that on Ubuntu using the terminal it would be something similar to
sudo apt-get install vlc
and there's probably 15 different flavors of that, which is fine, I can deal with that, but is it possible to do that from within a running Java application (and wait until it's finished before moving on), and if so, how can I go about doing that, and if not, how hosed am I?
To detect if LibVLC is already installed it's possible to do that in pure Java simply by searching the file-system using Java File IO. The idea is you'd look for "libvlc.so.*" in "/usr/lib" and/or other "well-known" locations.
vlcj provides a NativeDiscovery class that will do this for you:
boolean foundLibVLC = new NativeDiscovery().discover();
You can find Javadoc here.
You could then throw up a dialog box to prompt the user to install vlc using their package manager.
Or you could detect the OS by using Java File IO to read "/etc/issue" and if it were Ubuntu you could launch a process to run "apt-get install", or a different package manager for a different distro. I've used Apache Commons-Exec to do this sort of thing before.
There's simply no universal package manager you can assume across the different distros.
I know it's not ideal, but this is what I do for my projects.
To be fair, if you're targetting users on Linux you're likely to be targetting more technically savvy users than most and they would likely have no problems installing other software.
A further option I suppose is to ship the VLC source code with your project and have your installer build VLC. It takes a while to build VLC from scratch though, and there are lot of third party library dependencies that must be installed first.
I suppose on Linux, the 'correct' thing to do is to create a distro package (like a .deb or .rpm or something), declare a dependency on VLC, Java and JNA and do it that way.
I make my executable jar in exe format, but I want to add JRE with this because if JRE is not present in their machine, they can use it with this included JRE.
But I do not want to install this JRE in their machine. This JRE is only used by this application only. It will just like game or other application. I use launch4j to make jar to exe but i did not find any option from where it can attach JRE and it has no option from where I can link my jar dynamically.
How do I achieve that?
If there is other free installer then mention it, and please give the procedure with example.
Since it has been established that your app. has a GUI, I will suggest Java Web Start as the answer.
But I do not want to install this JRE in their machine.
That is not a sensible requirement. The user might already have a usable JRE installed, if they don't they probably also don't want every Java based application to be installing its own 'private' JRE.
Oracle's deployJava.js can do the checking, and help guide the user through the steps of installing (which basically comes down to click 'OK' when prompted).
I make my executable jar in exe format,..
If you only intend to support Windows, what is the attraction of coding in Java? JWS supports any platform for which Java is available. That brings a lot more potential customers for the app.
I want to use free installer.
JWS is entirely free. Just like the JRE.
..please give the procedure with example.
Do you run an IDE? If not, do you otherwise have Ant installed? If that is a yes to either one, check out my small JNLP API examples. Each comes with complete source and a build file (an Ant build.xml).
Within a couple of keystrokes & a few moments, you can see the app. installed and launched on your desktop. For the end user, it is even simpler. Just click a link in a web page, and it all happens automatically (possibly with a security prompt - for the protection of the user).
I like JSmooth. You can give it a try here:
http://jsmooth.sourceforge.net/features.php
Flexible automatic Java VM detection
Detects the location of any Sun JVM installed. The wrappers use
several strategies to detect all the JVM available on a computer,
using windows registry, environment variables, windows path.
Detects
and uses Microsoft's JView (for 1.0 and 1.1 Java applications), if
available.
The JVM search sequence is fully customizable using the
GUI. You can force the executable to search in the path first, and in
the registry last, or in JAVA_HOME first. We have all the flavours!
Sometimes it's more convenient to bundle a JRE with your application.
JSmooth can deal with that too, you just need to define in which
folder the JRE is expected. It falls back nicely to a standard JVM
search if the JRE is not where it should be.
Specify which versions of
the JVM are compatible with your software. You can set a minimum
version, but also a maximum JVM version.
Documentation: http://jsmooth.sourceforge.net/docs/jsmooth-doc.html
Take a look at launch4j.
I had to use it, and it worked out very well.
You can set a minimum version of a needed JRE, bundle a JRE, or if a JRE is not found (and not bundled) the launcher may lead the user to a download location of an appropriate JRE.
There are various further features launch4j offers, and as opposed to another suggestion here, launch4j is activly developed
http://launch4j.sourceforge.net/
I have used these three open source tools for packaging my java apps, but they all look like abandon-ware now. All three are very good pieces of software. What are the options now? (or is using Java for desktop app development no longer a "hot" market for app developers to build & maintain these tools?).
1) exe wrapper:
jsmooth - no new development in 2.5 years - does not support 64 bit.
launch4j - no new development in over a year, supports 64 bit, but you can't sign the exe created by launch4j, so I prefer jsmooth, but it does not support 64 bit.
2) onejar:
It works, but there has been no new development or web site update in more than 2.5 years. So, just want to switch to something that's supported / have a backup plan if it suddenly breaks with a new build of Java.
Thanks
Edgar
Launch4j has just been updated ! http://launch4j.sourceforge.net/changelog.html
Did you check IzPack? This is a great piece of software to create cross-platform installers:
IzPack is an installers generator for the Java platform. It produces lightweight installers that can be run on any operating system where a Java virtual machine is available. Depending on the operating system, it can be launched by a double-click or a simple 'java -jar installer.jar' on a shell. The most common use is to distribute applications for the Java platform, but you can also use it for other kinds of projects. The main benefit of IzPack is that it provides a clean and unique way of distributing a project to users using different operating systems.
Some really famous companies and projects use it for many years (Sun Microsystems, JBoss/RedHat, the Scala language project, some ObjectWeb/OW2 projects, XWiki and many more). If it's good for them, it should be good for you :)
Since none of the answers were approved, and JavaFX 2.2 has not been mentioned above (was not available at the time of the answers) here goes:
JavaFX 2.2 (part of Java Runtime and SDK since 7u6) allows building native exe/dmg/rpm's that tag along the full RT component as well. I believe this is a valid answer to your need, as well as an officially supported solution from Oracle.
https://blogs.oracle.com/talkingjavadeployment/entry/native_packaging_for_javafx
Have you tried IzPack (http://izpack.org/)?
You can try
http://winrun4j.sourceforge.net/
Has an exe with 64bit support and is quite easy to configure with an ini file.
As I was fed up with recent security changes in Java Webstart, I created my own tool, JNDT. It's under GPL.
It goes farther than akauppi's suggestion because it allows to create GNU Linux packages even under Mac and Windows :) I use it to create Mac bundle under GNU Linux too. For the moment, it's just a single Ant library with a few dependencies that allows to create native self-contained application bundles for GNU Linux, Mac OS X and Windows. I use it for my first person shooter and I'm very happy with it. It bundles the JRE but it can use the system JRE if you want.
P.S: JNDT is able to create a native Windows installer as an executable with NSIS even under GNU Linux.
I understand that the GPL license discourages some developers to use my tool. In this case, rather use PackR.
Maven 2 provides the ability to create a jar which contains all the dependencies as part of its assembly plugin. This combined with the jar plugin configuration of the manifest file (and specifically setting Main-class to the Class with main) is all you need to do basic packaging.
To some extent Java web start is now considered the better way to distribute Java applications and Maven 2's assembly capability combined with web start gets you everything you need without going via the exe route.
If you just want an exe (instead of a full-blown installer) you can make one with NSIS:
http://nsis.sourceforge.net/Java_Launcher_with_automatic_JRE_installation
Yes, NSIS is an installer but you can have it just run a jar in the same directory by stripping out all of the installer stuff. Basically it works like launch4j but is a lot more configurable.
If you are using gradle, there is a plugin that uses launch4j (under the hood) and works great. It doesn't even require you to download or install launch4j, it is totally automated.
https://github.com/TheBoegl/gradle-launch4j
I've got a Java application that I'm writing an installer for. We're using the AdvancedInstaller program to create our installer (well, we're evaluating it currently, but will definitely purchase a license soon), and although it has special support for Java applications, it is geared more towards repackaging them as desktop-type apps, and our software is a series of Java services and other utilities which doesn't make sense to distribute in EXE-wrappers. The target audience for this software is very specific, and we know that our software will probably be automatically distributed on freshly-imaged Windows 2003 Server machines. So requiring Java as a prerequisite basically makes more work for some poor sysadmin, and I'd rather avoid that if at all possible by repackaging the JRE's installer inside of our own.
I discovered that if I tried to execute the JRE's installer as a pre-install step from my MSI, it complains that another installer is already running (mine, of course), so it bails out. When I try to add the JRE installer as a software prerequisite in the AdvancedInstaller project (as a bundled EXE, not a URL link), it never seems to actually get installed, despite me trying to force-install it.
What's the best way to repackage the JRE? I'm not really a Java guy, so I don't know too much about how other developers deal with this same problem, short of requiring their users to hunt out and install the JRE on their own. The ideal solution here would be for us to find a EXE installer which can be executed from inside of another MSI installer, or if it's possible, to just package all of the files inside of the JRE and then create the appropriate registry and environment variables. How should I go about doing this?
I have not idea if this is "the way" to do it, but confronted with a somewhat similar problem, we simply archive an installed JRE with the rest of our application files and make sure that all our start scripts don't use java ..., but rather ..\..\jre\bin\java ... or similar. The JRE is unpackaged as part of our installation process in a subdirectory of where we install and that's that.
I agree with bdumitriu's answer:
a simple zip of a jre is enough, unless you want to link that jre to:
default java (meaning you must add java.exe of the unzipped jre to the path, before any other java path references)
default java for some script (you could define JAVA_HOME as referencing your new unzipped jre, but that may have side effects on other script also using JAVA_HOME before that new JRE)
file associations like .jnlp or .jar files (this requires some registry modifications)
browser java plugin registration (which requires also registry modifications)
If the last two points do not interest you on the desktop concerned by this deplyment, a simple zip is enough.
http://www.syswow64.co.uk/2013/05/java-7-update-21-1721-enterprise.html
The issue on many blogs and articles is around creating the 'deployment.config' and 'deployment.properties' files for an enterprise deployment. In my case i wanted to set the security level to 'Medium', but everytime I open the Java control panel it was set to the default HIGH setting.