mvn install with packageType=jar & include=runnable not installing the runnable JAR #1239
Comments
|
@tomcruise81 To get a runnable jar, you should use the |
|
From https://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html#a-build-lifecycle-is-made-up-of-phases, we understand that the
To ensure that this plugin operates that way, we have our pom configured as such: <!-- Enable liberty-maven plugin -->
<plugin>
<groupId>io.openliberty.tools</groupId>
<artifactId>liberty-maven-plugin</artifactId>
<version>3.3.4</version>
<!-- This is necessary to allow for <packaging>liberty-assembly</packaging> -->
<extensions>true</extensions>
<configuration>
<looseApplication>true</looseApplication>
<deployPackages>all</deployPackages>
<assemblyArtifact>
<groupId>io.openliberty</groupId>
<artifactId>openliberty-kernel</artifactId>
<version>${openliberty.runtime.version}</version>
<type>zip</type>
</assemblyArtifact>
</configuration>
<!-- This causes mvn package to create a runnable JAR file -->
<executions>
<execution>
<id>package-server</id>
<phase>package</phase>
<goals>
<goal>package</goal>
</goals>
<configuration>
<packageType>jar</packageType>
<include>all,runnable</include>
</configuration>
</execution>
</executions>
</plugin>so that during the default However, beyond that, we utilize the other standard Maven phases specified at https://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html#a-build-lifecycle-is-made-up-of-phases, including:
We don't call |
|
@tomcruise81 From your previous comment, I wasn't sure if there was a question or outstanding issue? Were you able to get the |
|
The Maven This plugin generates the runnable JAR, but doesn't convey to the rest of Maven that it ever generated that runnable JAR. So |
|
@cherylking - are you saying that I shouldn't be using Is there a mechanism for creating a runnable JAR via the default packaging type? |
That is exactly what I was saying. Usually the packaging type would be |
|
If I try setting |
|
@tomcruise81 Did you create the Liberty server and install the features before calling This is what is defined in the |
Is this a SpringBoot application? If not, the |
|
It is not a SpringBoot application. However, the intent of making it an uber JAR is to allow it to function in a fashion similar to SpringBoot - i.e. to run in an isolated fashion on a distinct JVM/JDK without a prior Liberty installation. The expectation is that it should be able to run on a clean VM / container that solely contains a JVM/JDK simply by calling This seems consistent with https://openliberty.io/guides/getting-started.html#running-the-application-from-a-minimal-runnable-jar. As such, I'm not calling other goals. My expectation is that I should be able to just call
|
|
@tomcruise81 Thanks for the explanation. I understand your use case now. Two points -
Let me know if following the above steps does not work as I have documented. On a side note, you are not the first person who has expressed the desire for the |
|
I've tried changing to: <?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 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
....
<packaging>jar</packaging>
...
<build>
<finalName>${project.artifactId}</finalName>
<plugins>
...
<!-- Enable liberty-maven plugin -->
<plugin>
<groupId>io.openliberty.tools</groupId>
<artifactId>liberty-maven-plugin</artifactId>
<version>3.3.4</version>
<!-- This is necessary to allow for <packaging>liberty-assembly</packaging> -->
<!-- <extensions>true</extensions> -->
<configuration>
<looseApplication>true</looseApplication>
<deployPackages>all</deployPackages>
<!--
<assemblyArtifact>
<groupId>io.openliberty</groupId>
<artifactId>openliberty-kernel</artifactId>
<version>${openliberty.runtime.version}</version>
<type>zip</type>
</assemblyArtifact>
-->
</configuration>
<!-- This causes mvn package to create a runnable JAR file -->
<executions>
<execution>
<id>prepare-package</id>
<phase>prepare-package</phase>
<goals>
<goal>install-server</goal>
<goal>create</goal>
<goal>install-feature</goal>
</goals>
</execution>
<execution>
<id>package</id>
<phase>package</phase>
<goals>
<!-- Can't use deploy goal as it isn't supported for jar packaging -->
<!-- <goal>deploy</goal> -->
<goal>package</goal>
</goals>
<configuration>
<packageType>jar</packageType>
<include>all,runnable</include>
<attach>true</attach>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
</project>I end up with the following in Of note: Looking at that code in the plugin, I'm not seeing why there'd be an issue with the comparison... |
|
@tomcruise81 Can you try removing the |
|
That made some progress. However, using the default packaging (i.e. jar), I'm precluded from using the So at this point:
|
|
Ok, so typically the |
|
@tomcruise81 I set up a multi-module project locally with two sub modules - one for building the war application, creating the Liberty server, installing the features and deploying the application - and another for packaging the Liberty server. Both the war file and the runnable jar file ended up in the .m2 repo after running Directory package-file-multi-module pom.xml Directory deploy-app pom.xml (under directory package-file-multi-module) Note: I had a server.xml in src/main/liberty/config with the necessary features for the war application and the Directory make-package pom.xml (under directory package-file-multi-module) Note: I did not include a Let me know if you get this working. I will use this issue to fix the bug in PackageServerMojo, but want to make sure you do not run into any other issues first. |
|
@cherylking - thanks for continuing to dig into this! How does that |
|
@tomcruise81 The module names in the main module refer to the directory names for the sub-modules. The artifactId in the sub modules can be anything. The |
|
So my directory structure was: package-file-multi-module |
|
Sorry, thanks for clarifying. I don't do much with multi-module Maven. |
|
I've gone ahead and created https://github.com/tomcruise81/openliberty-uber-jar to give a complete example (based off of all of your help @cherylking - thank you once again) of how to accomplish this. It'd truly be fantastic if this could be accomplished with a single module. But as I have a path forward, I'm off to more pressing matters. Thanks again! |
|
@tomcruise81 Glad you were able to get it working. I'm going to reopen this issue to fix the bug in |
|
Thanks! Should "jar" also be added to to facilitate moving away from multi-module and potentially allowing a simpler approach to this? |
I don't think it is as simple as that. When building a war/ear, there are other plugins involved. I'm not sure changing the project artifact from the produced war/ear to the packaged jar would be ok (unintended side affects). Also, how would the war/ear get built and deployed to Liberty if the |
When using
<packaging>liberty-assembly</packaging>, the Maveninstallphase seems to ignore runnable JARs.Note at the end that the
maven-install-pluginis treating the runnable .jar file as a .zip:The text was updated successfully, but these errors were encountered: