brianm / really-executable-jars-maven-plugin

maven plugin for making chmod +x jar files

really-executable-jar-maven-plugin

Usage

There is an introductory blog post at http://skife.org/java/unix/2011/06/20/really_executable_jars.html

To use:

1. Make sure you build an "uberjar" with a main class in the MANIFEST. See the Maven Shade plugin's documentation for one way of doing this.
2. Add this plugin to your build to make the JAR directly executable. All configuration parameters are optional; the defaults should work for many cases.

<plugin>
  <groupId>org.skife.maven</groupId>
  <artifactId>really-executable-jar-maven-plugin</artifactId>
  <version>2.1.1</version>
  <configuration>
    <!-- (optional) flags to be interpolated into the java invocation -->
    <!-- as "java $flags -jar ..." -->
    <flags>-Xmx1G</flags>
    
    <!-- (optional) input file name: only this specific file will be made executable -->
    <inputFile>target/fooBla.jar</inputFile>
    
    <!-- (optional) classifier name: only artifacts with this classifier are made executable -->
    <classifier>shaded</classifier>

    <!-- (optional) support other packaging formats than jar -->
    <allowOtherTypes>true</allowOtherTypes>

    <!-- (optional) name for a new binary executable, if not set will just
         make the original artifact executable -->
    <programFile>nifty-executable</programFile>
    
    <!-- (optional) name for a file that will define what script gets
         embedded into the executable jar.  This can be used to
         override the default startup script which is
         `#!/bin/sh
         
         exec java " + flags + " -jar "$0" "$@" -->
    <scriptFile>src/packaging/someScript.extension</scriptFile>
  </configuration>
  <executions>
    <execution>
      <phase>package</phase>
      <goals>
        <goal>really-executable-jar</goal>
      </goals>
    </execution>
  </executions>
</plugin>

Changes

2.1.1

• Overwrite existing files (@dkfellows)

2.1.0

• use zip-prefixer instead of rebuilding JAR (@klausbrunner)
• improve handling of multi-artifact builds (@klausbrunner)
• add inputFile parameter to select any file (@klausbrunner)
• add basic integration testing (@klausbrunner)
• require JDK 11+ to build (plugin still targets JDK 8)

2.0.0

• support ZIP64 format
• require Java 8, drop support for JDK7
• support packaging other file formats than jars

1.4.0

• require Java 7, change code to use JDK7 APIs
• Support Windows
• Don't suppress errors

1.3.0

• add helpmojo
• allow attachment of executable instead of unconditional replacement
• make extension configurable
• allow script replacement in the resulting executable

1.2.0

• never released

1.1.0

• If programFile is set, do not make the base artifact (the .jar) executable, just the programFile one.

1.0.0

• Stable

really-executable-jars-maven-plugin's Issues

Can't create executable on Windows

Currently, it fail with missing chmod, see attached screenshot.

I guess that on non-unit systems this step should be skipped.

scriptFile needs to be in the shaded jar but README suggests otherwise

The README suggests that the scriptFile can be some file somewhere in the project (src/packaging/someScript.extension) but actually it currently has to be in the shaded jar (https://github.com/brianm/really-executable-jars-maven-plugin/blob/master/src/main/java/org/skife/waffles/ReallyExecutableJarMojo.java#L169-170).
Either the README should be updated or the plugin should use file resolution instead of the classloader.

Add an explicit LICENSE.txt or LICENSE.md

Can you please add an explicit LICENSE.txt or LICENSE.md file?

Inconsistent behaviour of programFile with multiple artifacts

The current handling of programFile seems to make little sense when multiple artifacts exist. Basically, the first artifact that's in the list will be processed just fine, but then the next one would be copied over that same programFile again - except it won't, because the default behaviour of Files.copy() is to just fail if the target exists. Meaning there is no way this code will work with multiple artifacts:

               for (File file : files) {
                    File dir = file.getParentFile();
                    File exec = new File(dir, programFile);
                    Files.copy(file.toPath(), exec.toPath());
                    makeExecutable(exec);
                    if (attachProgramFile) {
                        projectHelper.attachArtifact(project, programFileType, exec);
                    }
                }

I think the sane thing to do is to bail out when multiple artifacts are encountered and programFile is set, instead of a futile loop.

Uploading to maven central

Do you know of any techniques that would allow the executable jar to be uploaded to a Maven Repository with the rest of the artifacts?

How to make a executable file for windows

Hi,
I cannot find how to make a executable file for windows (either CMD or Powershell).
Any idea of how to do that?

Add output filename option

Would be nice if there were an option for specifying the output filename, which would also leave the original jar untouched and instead create a new file and maybe even attach it to the project.

Add additional classpath elements

First of all, this little plugin has been a lifesaver to make CLIs that are portable across Mac/Linux (using this) and Windows (using Launch4j). My CLI now has over 100 MB of messy dependencies, and for mostly mysterious reasons it throws an error on the .exe side. I can get it to work if I leave my biggest dependency out of the shaded jar, and tell Launch4j to add an additional classpath element using the <postCp> configuration (which adds additional classpath elements). But now, the *nix shaded jar is also missing that dependency. How hard would it be to add support for that here? or can you help me with writing an extension to the launcher .sh?

Output file location for the newly created really executable jar

It would be nice if you could specify a path in the name of the output file, or specify a directory path as a different property altogether so that the finished really executable jar would end up in whatever directory or path. Right now it defaults to target/, but I want it to end up in /my/special/path. Am I making sense?

Great plugin! :)

Plugin shouldn't rebuild the original ZIP silently

I've run into a weird problem related to GraalVM's native-image when using this plugin. Weird because my assumption had been "it just prepends a few bytes to the original file, what could possibly go wrong", but actually it rebuilds the whole ZIP from scratch and may introduce Zip64 format when doing so.

This was added in 94051ac by @wendigo and it's unclear to me why this plugin should do anything like that. The only benefit I see is that it can be idempotent (i.e. doesn't stupidly prepend the same bytes again when called repeatedly).

The format change may be useful in some scenarios, but those seem completely independent of making it "really executable". Am I missing something here? Perhaps this behaviour should be explicitly enabled by a flag?

Adjust offsets on produced jar

Doing a

zip -A target/thething.jar

Will properly adjust the offsets on the end record muckery so that the jar stops complaining when being loaded as a jar :-)

Configurable input-jar

I lost an hour pulling my hair when setting the <programFile> parameter caused it to overwrite my shaded and obfuscated jar, instead of using it as input. Would be useful to have a parameter for specifying the input instead of picking the 'default' jar, especially when you have a multi-stage build process.