I would like to create a RPM package for my Java game (currently packaged as JARs + JNLP file). I use Ant as a build tool. I cannot use platform-dependent tools as the few developers who use my source code use several operating systems, not necessarily GNU Linux unlike me.
At first, I tried to use JDIC but its source code hasn't been maintained for years and I had to modify tons of things just to make it compile anew. Moreover, it just calls the native RPM tools under the hood. Then, I found RPM Ant task but it uses the native RPM tools under the hood too. After that, I found RPM Maven plugin but I don't want to switch to another build tool now just to create a RPM package.
Finally, I found Redline RPM pure Java library which has an Ant task, there is an example here. I still don't understand how to use it. I understand the role of a few basic fields (group, version, release, name), I know that I have to use "depends" to indicate that my game requires at least Java 1.7 but I don't know what to do with my JARs, where to put the .desktop file for the desktop shortcut and where to put the bash script that calls the main class to run my game. As a first step, I'd like to create a binary package. I have found another example using this library here. Do I have to provide an uninstall script too? Should I use a postinstall script to copy the .desktop file into the desktop directory? Should I use a tarfileset for the third party libraries? I know it would be better to put the JARs into several RPMs but I want to succeed in doing something simple before doing more elaborated but cleaner things.
I wrote a simple tutorial on how to use redline here
Basically everything you have to do build an empty rpm is that :
org.redline_rpm.Builder builder = new Builder();
File directory = new File(".");
builder.setType(RpmType.BINARY);
builder.setPlatform(Architecture.X86_64, Os.LINUX);
builder.setPackage("name", "1", "1");
builder.setDescription("Description");
builder.setSummary("Summary");
builder.build(directory);
You can add dependency on certain commands : example
builder.addDependencyMore("tar", "0");
builder.addDependencyMore("python", "0");
builder.addDependencyMore("wget", "0");
Then you can add some pre-install script or post-install script and files too.
builder.setPostInstallScript(xxx);
File tarball = new File("/the/dir/of/your/file/file.tar.gz");
builder.addFile("/where/to/put/it/file.tar.gz", tarball);
Redline maven dependency
<dependency>
<groupId>org.redline-rpm</groupId>
<artifactId>redline</artifactId>
<version>1.2.1</version>
</dependency>
I solved my problem here. I just have to add a short script to run the application.
P.S: By the way, I now use my own tool (which uses Redline RPM under the hood), it's fully documented, free software (under GPL) and works for DEB, APP and EXE (via NSIS) too, it's called Java Native Deployment Toolkit.
Related
I have an application that works fine and that I can execute from a .jar file. But I want to know how to make it runnable from any computer even if there is no JRE or the JRE version is not the good one. I thought about a .exe file but don't know how to do it.
I made my code with Eclipse and it use jxl,jdom and jfx librairies.
I tried to use Inno Setup 5.5.6 but when in Eclipse I run my build.xml as Ant Build it return me an error that says :
"'Launching JFX Build - Myapp' has encountered a problem.
The achive : C:/Program%20Files/eclipse/plugins/org.eclipse.swt.win32.win32.x86_64_3.104.0.v20150528.jar which is referenced by classpath, does not exist."
JavaFX provides specific utilities for bundling your application as a native package, which is referred to as "Self contained application packaging". These utilities are provided as a command-line tool, or as ant tasks. Additionally, the common IDEs support this via wizards, either out of the box (NetBeans) or via a plugin (e(fx)clipse for Eclipse). The details of how to use any of these are far beyond the scope of a stack overflow question, but the basic documentation is available here. A tutorial for e(fx)clipse is here.
Briefly, for e(fx)clipse, you should double-click the build.fxbuild file that is created in your project. Under the "Overview" tab, find the "Packaging format" option, and select "All" (or the specific type of package you want to create).
Note that you can only create a package targeted at the platform on which you are building, so if you want to create packages for windows, Mac, and Linux, you will need access to all three types of machine.
I know I am late. I faced same problem a trick worked for me. Look at the given directory in the error message. It contains a space (C:/Program Files/...). Move your e(fx)clipse to another directory where the directory doesn't contains any space.
Not sure it will work your everyone or not but it worked for me.
Thanks
There are various tools that let you wrap your Java application in a Windows executable. Some tools are only simple installers, others allow you to bundle your application with a specific JRE version.
A widely used but commercial tool is install4j, but there is a bunch of other tools, such as WinRun4J.
I have a Java project that's paired with a bash script to make it easier to deploy on Linux. The script is a lot more complicated than this, but the part that matters is a section like this:
directory="/default/install/directory"
jarName = "myApp-0.0.1.jar"
command="/usr/bin/java -DARG=$argValue -jar $directory/$jarName"
When I update the version to 0.0.2, I would like maven to automatically change this line in my script, simply to:
jarName = "myApp-0.0.2.jar"
I'm sure this would involve maven-release-plugin in some way - possibly with sed -i, but my development machine is Windows so such tools are not so readily available (though I do use cygwin) - but I'm not really sure how. Thanks!
This is typically done by placing these kind of scripts as Maven resources.
Using Maven properties ('jarName = "myApp-${project.version}.jar"') instead of hardcoded values, and activating filtering on these resources will make this straightforward.
If these scripts should be packaged in a different way than just inside the JAR produced, the assembly plugin will be able to do the job.
This is the third time I've installed it. I had it working on Windows, and up until a few days ago on Linux. I've done all I can do and I don't understand how to run this Java program.
The source code is a folder with a lib, src some jars and a classpath and project file.
The classpath file makes some declarations like classpathentry=src/main and path=lib, path=src.
All of these make sense. There is a folder 'main' inside 'src'.
The tiny file I'm trying to run starts off by
import de.l3s.boilerpipe.demo
I'm trying to run 'Oneliner.java'. I cannot compile it.
No matter what/where that class file is, I cannot run it. It results in a noclassdeffound.
I've run it in the main, the src, the root, the demo, the ... anywhere.
I've tried compiling it in different directories, running it with various java command line switches that were recommended. Supposedly you can have it 'search' for the file, which I've yet to experience. The sheer stubbornness of this java environment is terrifying. And massively humiliating for me.
I had the same problem with installing it. The 'Getting Started' page is poor quality.
My solution was to use a python wrapper, which you can find here: https://github.com/misja/python-boilerpipe
It takes care of all of the dependencies you'll need (however, you might be missing jpype if you're on a Mac. In that case, you'll need to install it manually from: http://jpype.sourceforge.net/).
The best way to start using the boilerpipe algorithm (and to see what it is for) is to use the demo site:
http://boilerpipe-web.appspot.com/
If you want to integrate the boilerpipe library into your applications, or even intent to modify/improve the code, you will definitely need solid Java programming skills.
As a quick-start I suggest that you install a recent version of the Eclipse IDE for Java Developers and import boilerpipe-core as a project. This avoids pretty much of the classpath configuration, and almost everything should be set up correctly for you.
The classpath file you mentioned is probably ".classpath", which is part of the Eclipse project configuration. You don't need it unless you want an Eclipse project.
What's the best option for packaging and distributing a command line application written in Java, targetting OS/X and Unix?
The executable jar option seems fairly robust, and my distribution doesn't need to be super fancy, so right now I'm just thinking of plonking a bash script next to that with the relevant java invocation and being done with it.
I'm wondering if there's something similar to python's bdist package that would let me easily make nice installers for both target platforms. Or if there's some more obvious way that I'm missing where I can turn the entire distribution in to a executable file that wraps the jar in some way.
Since you are providing a CLI application it may be easiest to just provide the script you already mentioned. I usually try to keep it self-contained, e. g. not referencing external paths / using only relative paths etc. And maybe a readme.txt file.
If you would like to provide a full-blown installer, you might want to take a look at IzPack, a tool for generating installers for Java deliverables. It also allows the wizard to run in console mode, if you do not have a graphical environment available for installation (see the "Features" page in the link above).
I'm trying to use an open source java library to visualize nodes and edges in a graph, but I'm completely lost.
I have a bunch of jar files in a folder. Clicking on some of the jar files makes java swing windows pop open with graphs displayed. Clicking other jar files does nothing.
If I figured that out, would I just stick the jar files in there with the other ones, or would that still not work?
And if I ever figure out how to use these files, does that mean that I have to include them if I transfer my java project to another computer? How would I go about doing that?
I believe if you put the jars in your classpath, you can import and use classes just like you would a standard library. Figuring out the classpath can be confusing, but you can just set it when you start your jvm. Your IDE may have options for it, too.
Most java problems are classpath problems.
Have you included those libraries in your classpath?
If you are using eclipse, you could
Project - > properties -> Java build path ->addJar.
And the Jar file should be placed in a directory inside your workspace (lib/ for example)
If you have to take your project to another computer, you could take these steps
Before doing anything, export your project (as a Jar file, for example).
Save it into your favorite drive (cd / usb drive/ diskette/ tape).
On "the other" computer, you can import this project into your workspace
In Eclipse, you need to add libraries to the project build path.
In general, you need to provide dependencies via the classpath mechanisms at compile time and runtime. The precise mechanisms vary, but, for example, if you used the javac compiler, you would provide your libraries on the command line:
javac -classpath C:\dir\lib1.jar;C:\dir\lib2.jar foo/MyClass.java
These dependencies would also be required to invoke the app:
java -classpath C:\dir\lib1.jar;C:\dir\lib2.jar;. foo.MyClass
This page gives some good info, though googling for the term "classpath" should provide alternative sources.
You use it by including it in the classpath of your java application, that way you can reference it from your code. Here is a starter document. The JDK 1.6 has some easier options (such as specifying multiple jar files as *.jar). It is definitely a little complicated, but it is very worth knowing.
You should have documentation for these Jars. Some sounds like examples, but one must be the core graph modelling and rendering Jar. Hopefully the examples have source included.
Just add that Jar to your project in Eclipse (e.g., in a /lib folder in your project, then add it to the build path) and use the documentation to use the code. You can also use Eclipse to look inside the Jar file.
Unless there is no alternative, it probably isn't worth using a load of third party code that isn't documented at least on the API level, and without any source examples definitely not.