We Keep Coding

How do I set file permissions on a file when deploying an AWS Serverless Application with Maven

I want to deploy an AWS lambda function using the AWS Serverless Application Model with Maven. In the lambdas deployment zip file I want to include two external files (file1 and file2) that need to have executable permisions. (chmod 755 / -rwxr-xr-x). The files are both 64-bit ELFs
The files on my local machine have those permisions, however when built and deployed to AWS I can export and download the function from the online AWS lambda console to a ZIP and see that the deployed files now have the permisions -rw-r--r-- (chmod 644).
I have fixed this issue in Gradle before by quite simply doing something like filesMatching('file1') { mode = 0755 }
I am using:
java11
maven-shade-plugin 3.2.2
How do I achieve this in Maven? Here is the build portion of my pom.xml
<build>
<resources>
<resource>
<directory>files</directory>
<includes>
<include>file1</include>
<include>file2</include>
</includes>
</resource>
</resources>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-shade-plugin</artifactId>
<version>3.2.2</version>
<configuration>
</configuration>
<executions>
<execution>
<phase>package</phase>
<goals>
<goal>shade</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>

For anyone else having this issue, I ended up using maven-assembly-plugin as suggested by khmarbaise. My solution ended up looking like this:
This was the build section of my pom.xml
<build>
<plugins>
<plugin>
<artifactId>maven-assembly-plugin</artifactId>
<version>3.2.0</version>
<executions>
<execution>
<id>make-assembly</id>
<phase>package</phase>
<goals>
<goal>single</goal>
</goals>
<configuration>
<descriptors>
<descriptor>distribution.xml</descriptor>
</descriptors>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
Then I added the file "distribution.xml" to the same directory as the POM.xml. Which looked like this.
<assembly
xmlns="http://maven.apache.org/ASSEMBLY/2.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/ASSEMBLY/2.0.0 http://maven.apache.org/xsd/assembly-2.0.0.xsd">
<id>aws-lambda-package</id>
<formats>
<format>zip</format>
</formats>
<includeBaseDirectory>false</includeBaseDirectory>
<fileSets>
<fileSet>
<directory>files</directory>
<outputDirectory>./</outputDirectory>
<includes>
<include>file1</include>
<include>file2</include>
</includes>
<fileMode>0755</fileMode>
</fileSet>
</fileSets>
<dependencySets>
<dependencySet>
<outputDirectory>lib</outputDirectory>
</dependencySet>
</dependencySets>
As a side effect of doing this I could no longer use the name of the function as the value for the codeURI in the template.yaml. So I needed to change it to the location of the zip file created when maven clean install is ran. Which in most peoples cases will be located: <functionName>/target/<fileName>.zip.

Assembly plugin can't copy Java runtime image

I'm using assembly plugin to aggregate JRT (Java runtime image) and some app resources into end user distribution. The usage us pretty simple:
pom.xml
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-assembly-plugin</artifactId>
<executions>
<execution>
<id>assembly-win64</id>
<phase>package</phase>
<goals>
<goal>single</goal>
</goals>
<configuration>
<outputDirectory>dist/win64</outputDirectory>
<descriptors>
<descriptor>src/main/assembly/windows.xml</descriptor>
</descriptors>
</configuration>
</execution>
</executions>
</plugin>
windows.xml
<?xml version="1.0" encoding="UTF-8"?>
<assembly xmlns="http://maven.apache.org/ASSEMBLY/2.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/ASSEMBLY/2.0.0 http://maven.apache.org/xsd/assembly-2.0.0.xsd">
<id>windows</id>
<formats>
<format>dir</format>
</formats>
<includeBaseDirectory>false</includeBaseDirectory>
<fileSets>
... more resources
<fileSet>
<directory>target/runtime-images/win64</directory>
<outputDirectory>app</outputDirectory>
</fileSet>
</fileSets>
</assembly>
All paths are 100% correct. However, if target/runtime-images/win64 contains actual JRT image, assembly plugin just ignores it. Here how it looks in debug:
[DEBUG] FileSet[app/] dir perms: -1 file perms: -1
[DEBUG] The archive base directory is 'null'
No copy attempts, no errors, nothing. How do I know that path is correct? Because if I put some trash files into the same directory (instead of JRT image) everything works like a charm.
I use Windows, so it seems no specific file permissions magic required.
Is anyone else ever faced the same issue? Or are there any Maven alternatives to assembly plugin?

Wow, I've found the problem. It's not so obvious so I post it here, maybe it helps someone once.
I've declared all plugins in parent pom. No configuration, just versions, so I don't have to specify plugin version in each child module.
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-assembly-plugin</artifactId>
<version>${plugin.assembly.version}</version>
</plugin>
<plugin>
<groupId>org.moditect</groupId>
<artifactId>moditect-maven-plugin</artifactId>
<version>${plugin.moditect.version}</version>
</plugin>
</plugins>
</build>
Then in the child module I've used these plugins in order they have to be executed.
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-assembly-plugin</artifactId>
<executions>
... configuration
</executions>
</plugin>
<plugin>
<groupId>org.moditect</groupId>
<artifactId>moditect-maven-plugin</artifactId>
<executions>
... configuration
</executions>
</plugin>
</plugins>
</build>
But Maven inherits plugin order from parent pom.
I've never expected this thing can be so stupid.

I added CLI support for my java library, how can I conveniently expose this to my library users?

I maintain a Java library which recently added support for CLI commands, but I'm having trouble understanding how to actually expose this support.
How can I provide an easy command cross-platform that works with all the dependencies needed?
During my own testing I have either relied on Junit tests that I run from IntelliJ or on the Maven exec plugin. IntelliJ and Maven manage all the dependencies, but I can't expect my library users to do the same. I'm thinking of providing a .bat file for Windows users and an alias for Linux users, which act as a shortcut for:
java -cp all;the;jars.jar my.package.CliSupportingClass command --option value
Is there a better way?

This article explains it quite well, using appassembler-maven-plugin to assemble all the dependencies and producing a script helper and maven-assembly-plugin to bundle it all as an archive such as zip and tar.
The article uses version 2.4 of one of the plugins, where I updated for the latest 3.1.0. The only difference for our use case is that the <descriptor> tag is now nested in a <descriptors> tag.
Include both plugins either as standard build plugins or under a profile:
<profiles>
<profile>
<id>standalone-cli</id>
<build>
<plugins>
<!-- appassembler-maven-plugin -->
<!-- maven-assembly-plugin -->
</plugins>
</build>
</profile>
</profiles>
The appassembler-maven-plugin collects all dependencies for us and produces a script helper for windows and unix:
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>appassembler-maven-plugin</artifactId>
<version>1.8.1</version>
<configuration>
<repositoryLayout>flat</repositoryLayout>
<repositoryName>lib</repositoryName>
<showConsoleWindow>true</showConsoleWindow>
<platforms>
<platform>unix</platform>
<platform>windows</platform>
</platforms>
<programs>
<program>
<mainClass>org.simplejavamail.cli.SimpleJavaMail</mainClass>
<id>sjm</id>
</program>
</programs>
</configuration>
<executions>
<execution>
<phase>package</phase>
<goals>
<goal>assemble</goal>
</goals>
</execution>
</executions>
</plugin>
The maven-assembly-plugin then produces the archive(s):
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-assembly-plugin</artifactId>
<version>3.1.0</version>
<configuration>
<descriptors>
<descriptor>src/assembly/standalone-cli-descriptor.xml</descriptor>
</descriptors>
</configuration>
<executions>
<execution>
<id>assemble-all</id>
<phase>package</phase>
<goals>
<goal>single</goal>
</goals>
</execution>
</executions>
</plugin>
Finally standalone-cli-descriptor.xml tells maven-assembly-plugin what should be included in the archives and what type of archives should be produced:
<assembly
xmlns="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.2"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.2 http://maven.apache.org/xsd/assembly-1.1.2.xsd">
<id>standalone-cli</id>
<formats>
<format>tar</format>
<format>zip</format>
</formats>
<includeBaseDirectory>false</includeBaseDirectory>
<fileSets>
<fileSet>
<directory>${project.basedir}</directory>
<outputDirectory>/</outputDirectory>
<includes>
<include>LICENSE-2.0.txt</include>
<include>NOTICE.txt</include>
<include>RELEASE.txt</include>
</includes>
</fileSet>
<fileSet>
<directory>${project.build.directory}/appassembler</directory>
<outputDirectory>/</outputDirectory>
<includes>
<include>**/**</include>
</includes>
</fileSet>
</fileSets>
</assembly>

Gradle has an application plugin that creates a distribution zip file. Your users can unzip this to install it. It has all the dependencies in a lib folder and Windows bat files and *nix shell scripts to run the application in a bin folder.
I believe Maven has something similar.

maven get multi-module-project jars into one directory

I have a multi-module project where I build every project with tycho. Everything including the phase "install" works perfectly. Every module results in one artefact which are installed to my local maven repository...about 10 artefacts.
Now, I would like to make maven additionally copy all 10 artefacts to a local directory if the build successes. At the end, when I rebuilt my application, I should only see one directory with all (updated) artefacts.
Btw, how do the big companies get their product out of the maven repository?

You may define an aggregator module in your project, that has dependencies on all other projects and then use the maven-dependency-plugin to collect all jars
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<executions>
<execution>
<id>copy-libs</id>
<phase>package</phase>
<goals>
<goal>copy-dependencies</goal>
</goals>
<configuration>
<includeScope>runtime</includeScope>
<overWriteReleases>false</overWriteReleases>
<overWriteSnapshots>true</overWriteSnapshots>
<outputDirectory>${project.build.directory}/lib</outputDirectory>
</configuration>
</execution>
</executions>
</plugin>
Of course you can collect resource files like startup scripts etc using the same plugin. Create another execution
<execution>
<id>copy-sh-files</id>
<phase>package</phase>
<goals>
<goal>unpack-dependencies</goal>
</goals>
<configuration>
<outputDirectory>${project.build.directory}/scripts</outputDirectory>
<includes>bin/*.sh</includes>
</configuration>
</execution>
To put that all together into a single zip, you have to create an assembly file in src/assembly/zip.xml with that content
<assembly>
<id>zip</id>
<formats>
<format>zip</format>
</formats>
<fileSets>
<fileSet>
<directory>src/bin</directory>
<outputDirectory>.</outputDirectory>
<includes>
<include>*.cmd</include>
</includes>
<lineEnding>dos</lineEnding>
</fileSet>
<fileSet>
<directory>target/lib</directory>
<outputDirectory>lib</outputDirectory>
<includes>
<include>*.jar</include>
</includes>
</fileSet>
</fileSets>
</assembly>
and add the maven-assembly-plugin to your build plugins
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-assembly-plugin</artifactId>
<configuration>
<descriptor>src/assembly/zip.xml</descriptor>
<finalName>yourProjectFinalName</finalName>
</configuration>
<executions>
<execution>
<id>zip-bundle</id>
<phase>package</phase>
<goals>
<goal>single</goal>
</goals>
</execution>
</executions>
</plugin>
All these configuration are just one way to do it, but it is a good start. Big companies usually have various requirements for their packaging, including installers etc, so there is no one-size-fits-all solution and it's usually quite a process to get to the final solution.

Maven shade plugin Packaging DLL

I have to add to my project a JNI module.
I install the module in Maven as two different artifact: the jar library:
mvn install:install-file -DgroupId=com.test -DartifactId=ssa -Dversion=1.0 -Dpackaging=jar -Dfile=ssa.jar
and the runtime library with the DLL
mvn install:install-file -DgroupId=com.sirio -Dpackaging=ddl -DartifactId=ssa-runtime -classifier=windows-x86 -Dversion=1.0 -Dfile=SSADll.dll
In my maven project I add these dependecies:
<dependency>
<groupId>com.test</groupId>
<artifactId>ssa</artifactId>
<version>1.0</version>
</dependency>
<dependency>
<groupId>com.test</groupId>
<artifactId>ssa-runtime</artifactId>
<classifier>windows-${arch}</classifier>
<type>dll</type>
<version>1.0</version>
<scope>runtime</scope>
</dependency>
My problem is when I run the shade plugin goal to create a jar with dependencies, I get error:
Failed to execute goal org.apache.maven.plugins:maven-shade-plugin:2.3:shade (default) on project ....: Error creating shaded jar: error in opening zip file sirio\ssa-runtime\1.0\ssa-runtime-1.0-windows-x86.dll
How can I tell the shade plugin to do not unpack the dll?

Maybe what you need is to package differently. Make the shaded jar with all java classes and libraries you use and then package this jar and the DLL together in a Zip file to be released. For this you can use the maven-assembly-plugin with a descriptor for your zip, like this:
In your pom.xml:
<plugin>
<artifactId>maven-assembly-plugin</artifactId>
<version>3.3.0</version>
<configuration>
<appendAssemblyId>false</appendAssemblyId>
<descriptors>
<descriptor>zip.xml</descriptor>
</descriptors>
</configuration>
<executions>
<execution>
<phase>package</phase>
<goals>
<goal>single</goal>
</goals>
</execution>
</executions>
</plugin>
In zip.xml file:
<assembly xmlns="http://maven.apache.org/ASSEMBLY/2.1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/ASSEMBLY/2.1.0 http://maven.apache.org/xsd/assembly-2.1.0.xsd">
<id>release</id>
<formats>
<format>zip</format>
</formats>
<fileSets>
<fileSet>
<directory>target</directory>
<includes>
<include>myapp.jar</include>
</includes>
<outputDirectory>/</outputDirectory>
</fileSet>
</fileSets>
<files>
<file>
<source>your.dll</source>
<fileMode>0644</fileMode>
</file>
</files>
</assembly>
That way you have all you need to release in this zip. I don't know if that's the best solution, but maybe it solves the problem for your use case.

this solution worked for my JavaFX-OpenCV project
package your project without DLL files.
copy and paste your DLL files in the jar file directory.
now you can run your application because all DLL files are now on the classpath of your jar application.
your directory should be like this :
/target/application.jar
/target/your_DLL_files.dll

Also being new to Maven, it took me a while to solve a similar problem. This answer may help others.
Using com.microsoft.sqlserver:mssql-jdbc_auth with mssql-jdbc_auth-10.2.3.x64.dll as a dependency.
Fortunately the dll is a separate artifact from the mssql jdbc jar.
To stop the shade plugin trying to open the dll as a zip file....
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-shade-plugin</artifactId>
<version>3.2.4</version>
<executions>
<execution>
<phase>package</phase>
<goals>
<goal>shade</goal>
</goals>
<configuration>
<artifactSet>
<excludes>
<exclude>com.microsoft.sqlserver:mssql-jdbc_auth</exclude>
</excludes>
</artifactSet>
</configuration>
</execution>
</executions>
</plugin>
and then to put the dll into the same directory as the shaded jar file
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<version>3.1.2</version>
<executions>
<execution>
<id>copy-dependencies</id>
<phase>prepare-package</phase>
<goals>
<goal>copy-dependencies</goal>
</goals>
<configuration>
<outputDirectory>${project.build.directory}</outputDirectory>
<includeArtifactIds>mssql-jdbc_auth</includeArtifactIds>
</configuration>
</execution>
</executions>
</plugin>