maven plugin for making chmod +x jar files

Last update: Dec 8, 2022

Overview

To use it, add a plugin to your pom like

<!-- You need to build an exectuable uberjar, I like Shade for that -->
<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-shade-plugin</artifactId>
    <version>2.0</version>
    <executions>
        <execution>
            <phase>package</phase>
            <goals>
                <goal>shade</goal>
            </goals>
            <configuration>
                <transformers>
                    <transformer implementation="org.apache.maven.plugins.shade.resource.ServicesResourceTransformer"/>
                    <transformer implementation="org.apache.maven.plugins.shade.resource.ManifestResourceTransformer">

                        <!-- note that the main class is set *here* -->

                        <mainClass>com.example.Main</mainClass>
                    </transformer>
                </transformers>
                <createDependencyReducedPom>false</createDependencyReducedPom>
                <filters>
                    <filter>
                        <artifact>*:*</artifact>
                        <excludes>
                            <exclude>META-INF/*.SF</exclude>
                            <exclude>META-INF/*.DSA</exclude>
                            <exclude>META-INF/*.RSA</exclude>
                        </excludes>
                    </filter>
                </filters>
            </configuration>
        </execution>
    </executions>
</plugin>

<!-- now make the jar chmod +x style executable -->
<plugin>
  <groupId>org.skife.maven</groupId>
  <artifactId>really-executable-jar-maven-plugin</artifactId>
  <version>1.4.1</version>
  <configuration>
    <!-- value of flags will be interpolated into the java invocation -->
    <!-- as "java $flags -jar ..." -->
    <flags>-Xmx1G</flags>

    <!-- (optional) name for binary executable, if not set will just -->
    <!-- make the regular jar artifact executable -->
    <programFile>nifty-executable</programFile>

    <!-- (optional) support other packaging formats than jar -->
    <!-- <allowOtherTypes>true</allowOtherTypes> -->
    
    <!-- (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:

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

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

Comments

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.

opened by tomdz 7
Add support for executable ZIP64 jars

This change introduces usage of Apache Commons Compress to support jars in ZIP64 format. Previous plugin version had a hard limit of 64K entries in the executable jar. After this change, limit for entries is 2^64-1 files which should be enough for most of the cases.

opened by wendigo 2
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! :)

opened by dougli1sqrd 2
added optional support for other packaging formats

When creating a self contained war-file (including a jetty web server) I also want to make this really self executable.

I've added optional support via configuration.

opened by matthias-m 2
Load scriptFile from filesystem first

If scriptFile is available on the filesystem load from there. If not, fall back to loading from the jar. This restores the original, and intended behavior of the plugin. Fixes #12

opened by brianm 2
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.

opened by tomdz 2
Allow deployment of the executable through maven repos.

Adds two new options:

true|false

if true, adds the created executable as a build artifact.

Due to the way maven handles artifacts, it will be named ${artifactId}-${version}.. The program file type can be set with

exe and defaults to "sh".

It is not possible to install or deploy and artifact without an ending ("type" in maven speak).

opened by hgschmie 1
Lots of cleanup of IO operations, add Windows support

Move forward to JDK7, leaving anyone with JDK6 to drown in the sands of history. Lots of cleanup of resource handling, fix a leak of ClassLoader object, add Windows support (fixes #6)

Needs a bit more cleanup before merge, and probably a basepom 9 release.

opened by stevenschlansker 0
Fix IOException to not be swallowed inside MojoExecutionException

Previously, we invoked MojoExecutionException( Object source, String shortMessage, String longMessage ) which takes no 'cause', so instead let's use MojoExecutionException( String message, Exception cause )

opened by stevenschlansker 0
Add scriptFile parameter to allow users to specify the script that gets embedded

Currently, the plugin has a fairly basic script that it injects which doesn't allow for things like overriding jvm parameters from the command-line. It would be nice to have the ability to override such things, but it's not safe to assume that everyone will want it done the same way.

Instead of picking how it should be done, giving users the ability to specify the script that they want embedded seemed like the safest solution with minimal impact.

opened by cheddar 0
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?

opened by jdimeo 1
Bump plexus-utils from 2.0.4 to 3.0.16
Bumps plexus-utils from 2.0.4 to 3.0.16.

Commits

cf317f9 [maven-release-plugin] prepare release plexus-utils-3.0.16

26e3ae8 Remove incorrect tag element

99639d6 Little test to mimic ${project.artifactMap(g:a:c)} usage

5d46979 Needs to build with 1.7 because of some Java7 utils, but source/target needs ...

18bd77d We can't switch to Java7 yet while Maven still needs to run on Java6

3cf855c Remove release cruft

3196d4c ignore .java-version

57b636d changed XmlUtilTest to create test output directory

33091f9 Use the same method for finding the basedir as our other code.

a153249 MNG-5553 reworked dotted expressions interpreter

Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

@dependabot rebase will rebase this PR

@dependabot recreate will recreate this PR, overwriting any edits that have been made to it

@dependabot merge will merge this PR after your CI passes on it

@dependabot squash and merge will squash and merge this PR after your CI passes on it

@dependabot cancel merge will cancel a previously requested merge and block automerging

@dependabot reopen will reopen this PR if it is closed

@dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually

@dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)

@dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)

@dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

@dependabot use these labels will set the current labels as the default for future PRs for this repo and language

@dependabot use these reviewers will set the current reviewers as the default for future PRs for this repo and language

@dependabot use these assignees will set the current assignees as the default for future PRs for this repo and language

@dependabot use this milestone will set the current milestone as the default for future PRs for this repo and language

You can disable automated security fix PRs for this repo from the Security Alerts page.

dependencies
opened by dependabot[bot] 0
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.

opened by StaffanArvidsson 0
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 :-)
opened by brianm 1

Releases(really-executable-jar-maven-plugin-2.0.0)

really-executable-jar-maven-plugin-2.0.0(Dec 10, 2022)
This release requires Java 8 or better!

Support ZIP64 format (thanks @wendigo!)

Support packaging other files than jars (thanks @matthias-m)

Source code(tar.gz)
Source code(zip)
really-executable-jar-maven-plugin-1.4.0(Feb 9, 2015)
require Java 7

change code to use JDK7 APIs

Support Windows

Don't suppress errors

Source code(tar.gz)
Source code(zip)

Owner

Brian McCallister

GitHub

Packages your JAR, assets and a JVM for distribution on Windows, Linux and Mac OS X

About Packages your JAR, assets and a JVM for distribution on Windows, Linux and macOS, adding a native executable file to make it appear like a nativ