We Keep Coding

pom.xml that works (Could not find or load main class/no main manifest attribute)

I have spent several hours on this and I'm unable to get it done. For a Maven/JavaFX-Application I am trying to get an executable jar. But whenever I build it with its dependencies and execute it with java -jar Kvn-jar-with-dependencies.jar I get one of these errors:
When executing the Fat Jar:
Error: Could not find or load main class com.qohelet.kvn.MainApp
When executing the Jar which apparently doesn't contain the dependencies
no main manifest attribute, in Kvn.jar
I use netbeans 8.2 for development (this is one of the last versions which can run with the OpenJDK 1.8.0) and I can run my project any time using (or better, Netbeans uses it):
cd /home/qohelet/Projekte/Kvn; JAVA_HOME=/home/qohelet/jdk1.8.0_111 /home/qohelet/netbeans-8.2/java/maven/bin/mvn "-Dexec.args=-classpath %classpath com.qohelet.kvn.MainApp 'USER' 1 'Indonesia'" -Dexec.executable=/home/qohelet/jdk1.8.0_111/bin/java org.codehaus.mojo:exec-maven-plugin:1.2.1:exec
There had been an issue with the obtaining the dependencies due to the change by mvn to ssh, but I didn't even have maven installed before, it still worked. (Maven dependencies are failing with a 501 error), now one of the addresses in the project header contains a https instead of a http but I don't think this is much of an issue.
Currently the pom.xml looks like this, this is an edited version of https://maven.apache.org/plugins/maven-assembly-plugin/usage.html:
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>com.qohelet</groupId>
<artifactId>Kvn</artifactId>
<version>2.2</version>
<packaging>jar</packaging>
<properties>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
<maven.compiler.source>1.8</maven.compiler.source>
<maven.compiler.target>1.8</maven.compiler.target>
</properties>
<build>
<finalName>Kvn</finalName>
<plugins>
<plugin>
<artifactId>maven-assembly-plugin</artifactId>
<version>3.3.0</version>
<configuration>
<descriptorRefs>
<descriptorRef>jar-with-dependencies</descriptorRef>
</descriptorRefs>
<archive>
<manifest>
<addClasspath>true</addClasspath>
<classpathPrefix>lib/</classpathPrefix>
<mainClass>com.qohelet.kvn.MainApp</mainClass>
</manifest>
</archive>
</configuration>
<executions>
<execution>
<id>make-assembly</id> <!-- this is used for inheritance merges -->
<phase>package</phase> <!-- bind to the packaging phase -->
<goals>
<goal>single</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
<dependencies>
<!-- Various -->
</dependencies>
<name>Kvn</name>
</project>
This version gives me the mentioned error.
I found a different suggestion where the -Section is set up like that which apparently worked for a while, but for some reason it doesn't seem to be advised as Netbeans complains:
Problem: Project Problem: Project's main artifact is processed through
maven-shade-plugin, resolvable by:
org.netbeans.modules.maven.problems.ProblemReporterImpl$MavenProblemResolver#a5534d
unresolved
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-shade-plugin</artifactId>
<version>3.2.1</version>
<executions>
<execution>
<phase>package</phase>
<goals>
<goal>shade</goal>
</goals>
<configuration>
<transformers>
<transformer implementation="org.apache.maven.plugins.shade.resource.ManifestResourceTransformer">
<mainClass>com.qohelet.kvn.MainApp</mainClass>
</transformer>
</transformers>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
<resources>
<resource>
<filtering>true</filtering>
<directory>src/main/resources</directory>
</resource>
</resources>
</build>
A few months ago the project could still be built with the following -Section but this was mostly a result from trial and error until I had a working result:
<build>
<finalName>Kvn</finalName>
<plugins>
<!-- download source code in Eclipse, best practice -->
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-eclipse-plugin</artifactId>
<version>2.9</version>
<configuration>
<downloadSources>true</downloadSources>
<downloadJavadocs>false</downloadJavadocs>
</configuration>
</plugin>
<!-- Set a compiler level -->
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>2.3.2</version>
</plugin>
<!-- Maven Shade Plugin -->
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-shade-plugin</artifactId>
<version>2.3</version>
<executions>
<!-- Run shade goal on package phase -->
<execution>
<phase>package</phase>
<goals>
<goal>shade</goal>
</goals>
<configuration>
<transformers>
<!-- add Main-Class to manifest file -->
<transformer implementation="org.apache.maven.plugins.shade.resource.ManifestResourceTransformer">
<mainClass>com.qohelet.kvn.MainApp</mainClass>
</transformer>
</transformers>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
I am not sure if I interpret this correctly but can it be due to version changes in Java?
SO provides a lot of answer, but I am not able to get anything to work.
https://stackoverflow.com/a/589111/2516892 gets me the exact same error:
<build>
<plugins>
<plugin>
<artifactId>maven-assembly-plugin</artifactId>
<configuration>
<archive>
<manifest>
<addClasspath>true</addClasspath>
<mainClass>com.qohelet.kvn.MainApp </mainClass>
</manifest>
</archive>
<descriptorRefs>
<descriptorRef>jar-with-dependencies</descriptorRef>
</descriptorRefs>
</configuration>
<executions>
<execution>
<id>make-my-jar-with-dependencies</id>
<phase>package</phase>
<goals>
<goal>single</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
Similar to https://stackoverflow.com/a/4323501/2516892 with the following build section which doesn't return a Fat Jar but the same error.
What is the state of the art? How should it be done properly?
Thank you
Edit (1):
The structure of the Jar looks fine to me. 22Mb seems to be a reasonable size too. It a folder /com/qohelet/kvn/ which contains a MainApp.class
Using https://stackoverflow.com/a/574650/2516892 and compiling with
mvn clean compile assembly:single
weirdly results in a set of errors like
package javafx.beans.value does not exist
Which is odd as JavaFX is installed and I can run the program without any issue.
Netbeans is not doing much different:
cd /home/qohelet/Projekte/Kvn; JAVA_HOME=/home/qohelet/jdk1.8.0_111 /home/qohelet/netbeans-8.2/java/maven/bin/mvn clean install
But this results in a jar with only 254Kb, which I assume doesn't contain the dependencies. Including the make-assembly-part just creates the same error.
Using the 2nd one listed here https://maven.apache.org/plugins/maven-shade-plugin/examples/executable-jar.html is just the same error: Error: Could not find or load main class com.qohelet.kvn.MainApp, the archive is slightly smaller (19Mb) and again it contains a folder-structure: /com/qohelet/kvn/ which contains a MainApp.class

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.

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.

How to put maven zip dependency on classpath for Java tests

I have a Java project entirely consisting of junit/integration tests which is managed by maven. One of the dependencies is a zip archive, the contents of which I would like to be available on the classpath when the tests are run. Since maven does not put the content of a zip dependency on the classpath I have had to come up with what I consider to be a hacky workaround. I unpack the zip archive to a temp directory then copy one of the resulting directories into the /test-classes folder. I also had to make the clean step delete the temp directory. Here are the relevant parts of the pom:
<groupId>com.my.package</groupId>
<artifactId>test-project</artifactId>
<version>0.0.1-SNAPSHOT</version>
<name>My Test Project</name>
<properties>
<config.artifactId>environment-dev</config.artifactId>
<config.version>2.0.8-SNAPSHOT</config.version>
<tempDir>${project.basedir}/temp</tempDir>
</properties>
<build>
<plugins>
...
<!-- clean out our custom temp directory as well as the default dir during clean phase-->
<plugin>
<artifactId>maven-clean-plugin</artifactId>
<version>2.3</version>
<configuration>
<filesets>
<fileset>
<directory>${tempDir}</directory>
</fileset>
</filesets>
</configuration>
</plugin>
<!-- since the config dependency is a zip it does not get added to the classpath. So we extract
it to a temp dir, then copy the content we need into a directory on the classpath -->
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<version>2.8</version>
<executions>
<execution>
<id>unpack-config</id>
<phase>compile</phase>
<goals><goal>unpack-dependencies</goal></goals>
<configuration>
<includeGroupIds>com.my.package.config</includeGroupIds>
<includeArtifactIds>${config.artifactId}</includeArtifactIds>
<includeClassifiers>config</includeClassifiers>
<outputDirectory>${tempDir}</outputDirectory>
</configuration>
</execution>
</executions>
</plugin>
<!-- copy the content of the zip file that we extracted into a directory on the classpath -->
<plugin>
<artifactId>maven-resources-plugin</artifactId>
<version>2.6</version>
<executions>
<execution>
<phase>compile</phase>
<goals><goal>copy-resources</goal></goals>
<configuration>
<outputDirectory>${project.build.directory}/test-classes/TargetDir</outputDirectory>
<resources>
<resource>
<directory>${tempDir}/${config.artifactId}-${config.version}/TargetDir</directory>
<filtering>true</filtering>
</resource>
</resources>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
<dependencies>
...
<dependency>
<groupId>com.my.package.config</groupId>
<artifactId>${config.artifactId}</artifactId>
<version>${config.version}</version>
<classifier>config</classifier>
<type>zip</type>
</dependency>
</dependencies>
There must be a better way of doing this.
Can I force maven to treat the zip file as if it were a jar? The link I provided has a tantalising hint that this might once have been possible, but I can't find anything relevant in the documentation. This seems like such a simple thing to be able to do, I really hope I've just missed a config parameter somewhere. Can anyone suggest a better way of getting the content of a zip dependency onto the classpath?

I would unzip the dependency into a subdirectory of the target directory and add that directory to the additionalClasspathElements configuration of the surefire plugin.
<properties>
<config.artifactId>environment-dev</config.artifactId>
<config.version>2.0.8-SNAPSHOT</config.version>
<unzipDir>${project.build.directory}/addTestClasspath</unzipDir>
</properties>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<version>2.8</version>
<executions>
<execution>
<id>unpack-config</id>
<phase>compile</phase>
<goals><goal>unpack-dependencies</goal></goals>
<configuration>
<includeGroupIds>com.my.package.config</includeGroupIds>
<includeArtifactIds>${config.artifactId}</includeArtifactIds>
<includeClassifiers>config</includeClassifiers>
<outputDirectory>${unzipDir}</outputDirectory>
</configuration>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.17</version>
<configuration>
<additionalClasspathElements>
<additionalClasspathElement>${unzipDir}</additionalClasspathElement>
</additionalClasspathElements>
</configuration>
</plugin>
</plugins>
</build>
In this case you can omit the clean plugin config because everything is under the target folder which will be deleted by the clean plugin by default.
Sadly this configuration does only work on the command line and not within eclipse, because the m2e plugin does not honor the additionalClasspathElement. See the jira issue MNGECLIPSE-1213

Maven - generate archive of every dependency source

Is there a way to get an archive containing every dependency source as a separate artifact ?
What i know is that there is a way to download every source jar using the dependency-plugin as stated here. However these files are downloaded to the local repository.
What i try to achieve is:
Ship a JAR containing some runnable code. In addition a ZIP archive cotaining the source-code of shipped dependencies inside the JAR.

I needed to do something similar, except I also needed to filter the included sources to just those produced by teams at my company. You may use a combination of the maven-dependency-plugin and the maven-assembly-plugin to achieve this.
Here's the configuration I use.
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<configuration>
<overWriteReleases>false</overWriteReleases>
<overWriteSnapshots>true</overWriteSnapshots>
</configuration>
<executions>
<execution>
<id>retrieve-dependency-sources</id>
<phase>process-sources</phase>
<goals>
<goal>copy-dependencies</goal>
</goals>
<configuration>
<classifier>sources</classifier>
<outputDirectory>${project.build.directory}/dep-sources</outputDirectory>
<type>jar</type>
<failOnMissingClassifierArtifact>false</failOnMissingClassifierArtifact>
<prependGroupId>true</prependGroupId>
<outputAbsoluteArtifactFilename>true</outputAbsoluteArtifactFilename>
<excludeTransitive>false</excludeTransitive>
</configuration>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-assembly-plugin</artifactId>
<executions>
<execution>
<id>package-dependency-sources</id>
<phase>prepare-package</phase>
<goals>
<goal>single</goal>
</goals>
<configuration>
<appendAssemblyId>true</appendAssemblyId>
<attach>true</attach>
<finalName>${your.app.finalName}</finalName>
<descriptors>
<descriptor>src/main/assembly/dep-source-assembly.xml</descriptor>
</descriptors>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
And here is the assembly descriptor, dep-source-assembly.xml, which should be placed in src/main/assembly.
<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>dep-sources</id> <!-- whatever you'd like the classifier to be -->
<formats>
<format>zip</format>
</formats>
<includeBaseDirectory>false</includeBaseDirectory>
<fileSets>
<fileSet>
<directory>${project.build.directory}/dep-sources</directory>
<outputDirectory></outputDirectory>
<!-- Define the includes if you'd like to have sources only for certain
packages. For my use case, I needed to include just source files
produced elsewhere in my company, not commonly available jars like
Spring. -->
<includes>
<include>**/com.mycompany.*.jar</include>
</includes>
</fileSet>
</fileSets>
</assembly>
It sounds like your use case may be a little different than mine, so you might be able to use the assembly plugin's dependencySet in place of the separate invocation of maven-dependency-plugin and the fileSet.
One other potential gotcha: if you are doing this for a war or ear, you will need to add a dependency on the project's POM to get the complete set of dependencies. (See MNG-1991.)
<dependency>
<groupId>${my.webapp.groupId}</groupId>
<artifactId>${my.webapp.artifactId}</artifactId>
<version>${my.webapp.version}</version>
<type>pom</type>
</dependency>