This might be a duplicate, cause I can't image that we're the first to encounter this, but I can't seem to find it.
So, we are deploying WAR files to a tomcat 8.5 server with gitlab ci using maven. Issue is that tomcat messes up the versions when we moved from 0.2.9 to 0.2.10. Apparendly the server deploys the WARs in alphabetical order and 0.2.10 lies between 0.2.1 and 0.2.2 and the running version is still 0.2.9 even while 0.2.10 was correctly deployed to the server.
Full webapp name looks like: WebappName##0.2.10-SNAPSHOT_201901010000.war
We thought about renaming our versions to 0.2.009 and 0.2.010 but that seems like a rather dirty work-around. Of cause older versions will be deleted from time to time so it's not a permanent problem, but it's just somewhat annoying and any hints on how to solve this would be great.
From the pom.xml
<version>0.2.10-SNAPSHOT</version>
<properties>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
<maven.install.skip>true</maven.install.skip>
<timestamp>${maven.build.timestamp}</timestamp>
<maven.build.timestamp.format>yyyyMMddHHmm</maven.build.timestamp.format>
</properties>
[..]
<profile>
<id>deploy-stage</id>
<activation>
<activeByDefault>false</activeByDefault>
</activation>
<properties>
<war.name>WebappName##${project.version}_${timestamp}</war.name>
<tomcat.url>http://[..]/manager/text</tomcat.url>
<tomcat.server>[..]</tomcat.server>
<tomcat.webpath>/${war.name}</tomcat.webpath>
</properties>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<version>2.3</version>
<executions>
<execution>
<id>default-war</id>
<goals>
<goal>manifest</goal>
<goal>war</goal>
</goals>
<phase>package</phase>
</execution>
</executions>
<configuration>
<warName>${war.name}</warName>
<failOnMissingWebXml>true</failOnMissingWebXml>
<archive>
<addMavenDescriptor>true</addMavenDescriptor>
<forced>true</forced>
<manifest>
<addClasspath>true</addClasspath>
<packageName>true</packageName>
<useUniqueVersions>true</useUniqueVersions>
<addDefaultImplementationEntries>true</addDefaultImplementationEntries>
</manifest>
<manifestEntries>
<Build-Time>${maven.build.timestamp}</Build-Time>
<Archetype>${archetypeArtifactId}</Archetype>
<Archetype-Version>${archetypeVersion}</Archetype-Version>
</manifestEntries>
</archive>
<webResources>
<resource>
<filtering>true</filtering>
<directory>src/main/webapp</directory>
<includes>
<include>**/web.xml</include>
</includes>
</resource>
</webResources>
<warSourceDirectory>src/main/webapp</warSourceDirectory>
<webXml>src/main/webapp/WEB-INF/web.xml</webXml>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.tomcat.maven</groupId>
<artifactId>tomcat7-maven-plugin</artifactId>
<version>2.2</version>
<configuration>
<warFile>${project.build.directory}/${war.name}.war</warFile>
<url>${tomcat.url}</url>
<server>${tomcat.server}</server>
<path>${tomcat.webpath}</path>
</configuration>
<executions>
<execution>
<phase>deploy</phase>
<goals>
<goal>deploy</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
</profile>
From gitlab-ci.yml
variables:
MAVEN_OPTS: "-Dorg.slf4j.simpleLogger.log.org.apache.maven.cli.transfer.Slf4jMavenTransferListener=WARN -Dorg.slf4j.simpleLogger.showDateTime=true -Djava.awt.headless=true"
MAVEN_CLI_OPTS: "--batch-mode --errors --fail-at-end --show-version -DinstallAtEnd=true -DdeployAtEnd=true"
# Cache downloaded dependencies and plugins between builds.
cache:
paths:
- /root/.m2/repository/
stages:
- build
- deploy
# Run deploy
deploy:staging:
stage: deploy
script:
- 'mvn $MAVEN_CLI_OPTS -Dsonar.branch=$CI_COMMIT_REF_NAME deploy -am -P deploy-stage'
only:
- staging
image: maven:3.3.9-jdk-8
As the Apache Tomcat documentation says:
String comparisons are used to determine version order.
This is simply not the same as comparison of Maven artifact versions. A version of 2.0.2 is always larger by String comparison than 2.0.10 or even 2.0.15000 etc.
I guess you have something like this in your pom.xml:
<properties>
<buildTimestamp>${maven.build.timestamp}</buildTimestamp>
<maven.build.timestamp.format>yyyyMMddHHmm</maven.build.timestamp.format>
</properties>
<build>
<finalName>${project.artifactId}##${project.version}_${maven.build.timestamp}</finalName>
</build>
You can change that to:
<finalName>${project.artifactId}##${maven.build.timestamp}_${project.version}</finalName>
which yields a file name like WebappName##201901010000_0.2.10-SNAPSHOT.war.
This way the most current build by timestamp will be deployed as currently active application version.
Alternatively you can keep your version schema of the .war file name and instead have your app deployed using a versioned file name for your context.xml:
apache-tomcat/conf/Catalina/localhost/WebappName##201901010000.xml
with the content:
<Context docBase="/path/to/WebappName##0.2.10-SNAPSHOT_201901010000.war" path="/WebappName"/>
In Apache Tomcat Manager this will show up as version 201901010000 in application version column. Again the most current build by timestamp will be deployed as currently active application version independent of the Maven artifact version as the deployment version String is taken from the .xml file name instead of the .war file name.
Related
I have a multi-module Maven project where the project version is set via the revision variable.
<groupId>pricing</groupId>
<artifactId>pricing-backend-pom</artifactId>
<version>${revision}</version>
<packaging>pom</packaging>
<properties>
<revision>3.0.7</revision>
</properties>
<modules>
<module>pricing-backend-war</module>
<module>pricing-backend-model</module>
<module>pricing-backend-client</module>
</modules>
<build>
<plugins>
<!-- flatten before deploy. removes $revision -->
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>flatten-maven-plugin</artifactId>
<version>1.2.7</version>
<configuration>
</configuration>
<executions>
<!-- enable flattening -->
<execution>
<id>flatten</id>
<phase>process-resources</phase>
<goals>
<goal>flatten</goal>
</goals>
</execution>
<!-- ensure proper cleanup -->
<execution>
<id>flatten.clean</id>
<phase>clean</phase>
<goals>
<goal>clean</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
During the Gitlab build, the project is deployed to a Nexus repository. Each module and the parent appear in Nexus but only the modules appear to be flattened. The module POMs each contain <version>3.0.7</version> but the parent POM still contains <version>${revision}</version>.
I find it difficult to understand why the parent is deployed differently to the modules. I have checked the build logs but cannot see any indication that the parent is handled in a different way.
The parent POM taken from Nexus:
<groupId>pricing</groupId>
<artifactId>pricing-backend-pom</artifactId>
<version>${revision}</version>
<packaging>pom</packaging>
<properties>
<revision>3.0.7</revision>
...
A module POM:
<groupId>pricing</groupId>
<artifactId>pricing-backend-client</artifactId>
<version>3.0.7</version>
<dependencies>
...
The build applies the required version:
$ echo New version= ${MAVEN_VERSION}
New version= -Drevision=3.0.7-SNAPSHOT
$ mvn $MAVEN_CLI_OPTS ${MAVEN_VERSION} deploy -DskipTests
The pom file to be installed can be explicitly set:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-install-plugin</artifactId>
<version>2.4</version>
<configuration>
<pomFile>.flattened-pom.xml</pomFile>
</configuration>
</plugin>
Above, flatten-maven-plugin has been previously invoked to produce .flattened-pom.xml
If you do a test by adding -Drevision=<someVersion> to the command line, does that produce correct results in Nexus?
I suspect it will.
Properties are interpolated very early in the process. When the command first runs, ${revision} is undefined, so Maven leaves it as-is. The flatten then calculates ${revision}, but that only applies from the time the plugin runs and later.
You can try researching "late binding" properties (they start with '#' instead of '$') but I'm not sure if those work in top level fields like the GAV coords.
I'm trying to build a pom.xml to handle the deployment and undeployment to a remote TomEE (PluME 7.0.3) server. However, I cannot figure out the correct value to use in the path configuration tag. Here's a working plugin configuration for deploying my application (full-blown EAR, for educational purposes) to the remote TomEE:
<build>
<plugins>
<plugin>
<groupId>org.apache.tomee.maven</groupId>
<artifactId>tomee-maven-plugin</artifactId>
<version>7.0.3</version>
<configuration>
<context>someear</context>
<tomeeClassifier>plus</tomeeClassifier>
<tomeeHost>192.168.100.100</tomeeHost>
<debugPort>8000</debugPort>
<tomeeAjpPort>8009</tomeeAjpPort>
<tomeeHttpPort>8080</tomeeHttpPort>
<tomeeShutdownPort>8005</tomeeShutdownPort>
<path>target/someear-1.0-SNAPSHOT.ear</path>
<useBinaries>true</useBinaries>
</configuration>
</plugin>
</plugins>
</build>
Whereas to undeploy, I would have to configure the plugin like this:
<build>
<plugins>
<plugin>
<groupId>org.apache.tomee.maven</groupId>
<artifactId>tomee-maven-plugin</artifactId>
<version>7.0.3</version>
<configuration>
<context>someear</context>
<tomeeClassifier>plus</tomeeClassifier>
<tomeeHost>192.168.100.100</tomeeHost>
<debugPort>8000</debugPort>
<tomeeAjpPort>8009</tomeeAjpPort>
<tomeeHttpPort>8080</tomeeHttpPort>
<tomeeShutdownPort>8005</tomeeShutdownPort>
<path>someear-1.0-SNAPSHOT</path>
<useBinaries>true</useBinaries>
</configuration>
</plugin>
</plugins>
</build>
Notice the difference in the path configuration. From the command line, this behaves similarly; when the path tag in the pom.xml is omitted, I can deploy and undeploy like this:
mvn tomee:deploy -Dtomee-plugin.archive=target/someear-1.0-SNAPSHOT.ear
mvn tomee:undeploy -Dtomee-plugin.archive=someear-1.0-SNAPSHOT
Has anybody experienced the same behaviour, and found a way to mitigate this? I'd like to have both deploy and undeploy configured completely in the pom.xml without specifying additional parameters when calling mvn. But, as of now, I cannot do that, since tomee:deploy seems to expect a different path than tomee:undeploy.
EDIT
Ok, based on #Old School's edited answer, I can do something like this:
<profiles>
<profile>
<id>deploy</id>
<activation>
<activeByDefault>true</activeByDefault>
</activation>
<properties>
<my-tomee-maven-plugin-path>target/someear-1.0-SNAPSHOT.ear</tomee-maven-plugin-path>
</properties>
</profile>
<profile>
<id>undeploy</id>
<properties>
<my-tomee-maven-plugin-path>someear-1.0-SNAPSHOT</tomee-maven-plugin-path>
</properties>
</profile>
</profiles>
Then, specify path in tomee-maven-plugin's configuration section like this:
...
<path>${my-tomee-maven-plugin-path}</path>
...
Then, execute maven like this:
mvn tomee:deploy
mvn tomee:undeploy -Pundeploy
Which I consider more convenient than specifying some -D parameters at execution time (YMMV).
However, the perfect solution in my opinion would be if you could configure path in tomee-maven-plugin's configuration such that both tomee:deploy and tomee:undeploy work without further ado.
EDIT2
I discovered another possibility without profiles which I was seemingly unable to find before (based on: http://tomee-openejb.979440.n4.nabble.com/Deployment-to-TomEE-7-0-0-using-tomee-maven-plugin-error-Cannot-open-input-stream-to-server-tp4679142p4679282.html):
<plugin>
<groupId>org.apache.tomee.maven</groupId>
<artifactId>tomee-maven-plugin</artifactId>
<version>7.0.3</version>
<configuration>
<context>${project.artifactId}</context>
<tomeeClassifier>plus</tomeeClassifier>
<context>someear</context>
<tomeeClassifier>plus</tomeeClassifier>
<tomeeHost>192.168.100.100</tomeeHost>
<debugPort>8000</debugPort>
<tomeeAjpPort>8009</tomeeAjpPort>
<tomeeHttpPort>8080</tomeeHttpPort>
<tomeeShutdownPort>8005</tomeeShutdownPort>
<!-- no <path> tag -->
<useBinaries>true</useBinaries>
</configuration>
<executions>
<execution>
<id>deploy-it</id>
<phase>none</phase>
<goals>
<goal>deploy</goal>
</goals>
<configuration>
<path>target/someear-1.0-SNAPSHOT.ear</path>
</configuration>
</execution>
<execution>
<id>undeploy-it</id>
<phase>none</phase>
<goals>
<goal>undeploy</goal>
</goals>
<configuration>
<path>someear-1.0-SNAPSHOT</path>
</configuration>
</execution>
</executions>
</plugin>
Usage:
mvn tomee:deploy#deploy-it
mvn tomee:undeploy#undeploy-it
I use glassfish, not tomcat, but I think the same principles apply here. In GF, deploy requires the full path and the undeploy requires only the package name. For example, glassfish goes something like:
asadmin deploy C:\Projects\Java\helloworld\helloworld.war
and
asadmin undeploy helloworld
There is no path required on undeploy because the file is on the server and once you name it, glassfish/tomcat knows where it is.
EDIT based off comments: My apologies for the glassfish stuff, I wasn't paying attention to you mentioning tomcat and I've edited a bit to reflect that somewhat.
I do understand now, I think, what you're looking for. Check out:
Maven Resource Filtering
It's another SO answer where he does a fantastic job of explaining exactly what you're looking for, I think. I hope that works.
I’m using Maven 3.1.1 on Mac 10.9.1. I want to activate a profile based on whether certain child modules contain a file. I have tried the following
<profile>
<id>deploy-war-to-jboss</id>
<activation>
<file>
<exists>${session.executionRootDirectory}/src/main/webapp/WEB-INF/web.xml</exists>
</file>
</activation>
<build>
<plugins>
<plugin>
<groupId>org.jboss.as.plugins</groupId>
<artifactId>jboss-as-maven-plugin</artifactId>
<version>${jboss.maven.plugin.version}</version>
<configuration>
<hostname>${jboss.remote.hostname}</hostname>
<port>${jboss.remote.port}</port>
</configuration>
<executions>
<execution>
<id>deploy-to-jboss</id>
<phase>install</phase>
<goals>
<goal>deploy</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
</profile>
but this profile doesn’t get activated when running “mvm clean install” despite the fact I’ve verified that the child modules in question contain the file. I also tried ${project.basedir} without luck. Any ideas how I make this happen?
Since you define the profile in the parent POM (I guess) you should try this
${basedir}/name-of-your-child-module//src/main/webapp/WEB-INF/web.xml
Furthermore, you should try running Maven in debug mode to get more information at runtime:
mvm -X clean install
I´m trying to make a Maven Project from an existing web application using JSF. The Project
should be deployed on Web Sphere 8.5.
Since i'm new to Web Sphere, don´t know how to build the "ear" Module, in order to be deployable on Web Sphere 8.5.
Does anyone know, where i can find further Information about deploying a web application on Web Sphere 8.5 using Maven 3.0.3?
Thanking you in anticipation,
Mosen
I've never worked with WebSphere Application Server 8.5; but in the days I was playing with IBM WAS 6.1 the WAS6 Maven plugin worked pretty well (it seems it works with WAS7 too). Here's a POM fragment from the plugin site that allows automatic EAR deployment:
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>was6-maven-plugin</artifactId>
<version>1.2</version>
<executions>
<execution>
<id>integration-test</id>
<phase>integration-test</phase>
<goals>
<goal>installApp</goal>
</goals>
</execution>
</executions>
<configuration>
<wasHome>${was61home}</wasHome>
<host>deploymentmanager.your.domain</host>
<username>admin</username>
<password>adminpassword</password>
<targetCluster>nameOfCluster</targetCluster>
<profileName>Dmgr01</profileName>
<conntype>SOAP</conntype>
<port>8879</port>
<verbose>true</verbose>
<updateExisting>false</updateExisting>
</configuration>
</plugin>
That plugin is for deployment and other administrative task, for EAR generation you can use the Maven EAR Plugin as described in 20InchMovement answer.
Hope this could helps:
<plugin>
<groupId>com.orctom.mojo</groupId>
<artifactId>was-maven-plugin</artifactId>
<version>1.0.8</version>
<executions>
<execution>
<id>deploy</id>
<phase>install</phase>
<goals>
<goal>deploy</goal>
</goals>
<configuration>
<wasHome>${env.WAS_HOME}</wasHome>
<applicationName>${project.build.finalName}</applicationName>
<host>${local or remote address}</host>
<server>server01</server>
<node>node01</node>
<virtualHost>default_host</virtualHost>
<verbose>true</verbose>
</configuration>
</execution>
</executions>
</plugin>
From https://github.com/orctom/was-maven-plugin
in order to package an *.ear, you don't need Websphere.
This can be accomplished with maven itself.
pom.xml:
<project>
...
<artifactId>YourApp</
<packaging>ear</packaging>
...
<build>
<pluginManagement>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-ear-plugin</artifactId>
<configuration>
<modules>
<jarModule>
<groupId>${project.parent.groupId}</groupId>
<artifactId>configurationApp</artifactId>
</jarModule>
<ejbModule>
<groupId>${project.parent.groupId}</groupId>
<artifactId>AnEjbModule</artifactId>
</ejbModule>
</modules>
</configuration>
</plugin>
</plugins>
</pluginManagement>
</build>
...
</project>
Then you add your dependencies.
On command line go to your project and run mvn package.
Because of the package defined in you pom.xml, the ear will be created and can be found in the YourApp/target directory.
On the websphere admin console you can simply install the ear.
After login, goto:
Applications->Websphere enterprise applications and install a new application.
Select your YourApp.ear and go for easiness through the fast path to install the app.
The port to check is probably
yourServerName:9080/YourApp.
Good luck.
See http://code.google.com/p/websphere-maven-plugin/
Websphere Maven Plugin provides goals to:
deploy ear on websphere 7
start application
stop application
uninstall
require websphere application client.
I have a JAR in my Android project and I want it to be added to final APK.
Okay, here I go:
<dependency>
<groupId>com.loopj.android.http</groupId>
<artifactId>android-async-http</artifactId>
<version>1.3.2</version>
<type>jar</type>
<scope>system</scope>
<systemPath>${project.basedir}/libs/android-async-http-1.3.2.jar</systemPath>
</dependency>
But when I am running mvn package I am getting a warning:
[WARNING] Some problems were encountered while building the effective model for **apk:1.0
[WARNING] 'dependencies.dependency.systemPath' for com.loopj.android.http:android-async-http:jar should not point at files within the project directory, ${project.basedir}/libs/android-async-http-1.3.2.jar will be unresolvable by dependent projects # line 36, column 25
And in the final APK there are no JARs.
How do I fix that?
I don't know the real reason but Maven pushes developers to install all libraries (custom too) into some maven repositories, so scope:system is not well liked, A simple workaround is to use maven-install-plugin
follow the usage:
write your dependency in this way
<dependency>
<groupId>com.mylib</groupId>
<artifactId>mylib-core</artifactId>
<version>0.0.1</version>
</dependency>
then, add maven-install-plugin
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-install-plugin</artifactId>
<version>2.5.2</version>
<executions>
<execution>
<id>install-external</id>
<phase>clean</phase>
<configuration>
<file>${basedir}/lib/mylib-core-0.0.1.jar</file>
<repositoryLayout>default</repositoryLayout>
<groupId>com.mylib</groupId>
<artifactId>mylib-core</artifactId>
<version>0.0.1</version>
<packaging>jar</packaging>
<generatePom>true</generatePom>
</configuration>
<goals>
<goal>install-file</goal>
</goals>
</execution>
</executions>
</plugin>
pay attention to phase:clean, to install your custom library into your repository, you have to run mvn clean and then mvn install
You will need to add the jar to your local maven repository. Alternatively (better option) specify the proper repository (if one exists) so it can be automatically downloaded by maven
In either case, remove the <systemPath> tag from the dependency
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
<configuration>
<includeSystemScope>true</includeSystemScope>
</configuration>
</plugin>
Try this.
System scope was only designed to deal with 'system' files; files sitting in some fixed location. Files in /usr/lib, or ${java.home} (e.g. tools.jar). It wasn't designed to support miscellaneous .jar files in your project.
The authors intentionally refused to make the pathname expansions work right for that to discourage you. As a result, in the short term you can use install:install-file to install into the local repo, and then some day use a repo manager to share.
Try this configuration. It worked for me:
<plugin>
<artifactId>maven-war-plugin</artifactId>
<version>2.4</version>
<configuration>
<warSourceDirectory>mywebRoot</warSourceDirectory>
<warSourceExcludes>source\**,build\**,dist\**,WEB-INF\lib\*,
WEB-INF\classes\**,build.*
</warSourceExcludes>
<webXml>myproject/source/deploiement/web.xml</webXml>
<webResources>
<resource>
<directory>mywebRoot/WEB-INF/lib</directory>
<targetPath>WEB-INF/lib</targetPath>
<includes>
<include>mySystemJar1.jar.jar</include>
<include>mySystemJar2.jar</include>
</includes>
</resource>
</webResources>
</configuration>
</plugin>
Use a repository manager and install this kind of jars into it. That solves your problems at all and for all computers in your network.
mvn install:install-file -DgroupId=com.paic.maven -DartifactId=tplconfig-maven-plugin -Dversion=1.0 -Dpackaging=jar -Dfile=tplconfig-maven-plugin-1.0.jar -DgeneratePom=true
Install the jar to local repository.
Thanks to Ging3r i got solution:
follow these steps:
don't use in dependency tag. Use following in dependencies tag in pom.xml file::
<dependency>
<groupId>com.netsuite.suitetalk.proxy.v2019_1</groupId>
<artifactId>suitetalk-axis-proxy-v2019_1</artifactId>
<version>1.0.0</version>
</dependency>
<dependency>
<groupId>com.netsuite.suitetalk.client.v2019_1</groupId>
<artifactId>suitetalk-client-v2019_1</artifactId>
<version>2.0.0</version>
</dependency>
<dependency>
<groupId>com.netsuite.suitetalk.client.common</groupId>
<artifactId>suitetalk-client-common</artifactId>
<version>1.0.0</version>
</dependency>
use following code in plugins tag in pom.xml file:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-install-plugin</artifactId>
<version>2.5.2</version>
<executions>
<execution>
<id>suitetalk-proxy</id>
<phase>clean</phase>
<configuration>
<file>${basedir}/lib/suitetalk-axis-proxy-v2019_1-1.0.0.jar</file>
<repositoryLayout>default</repositoryLayout>
<groupId>com.netsuite.suitetalk.proxy.v2019_1</groupId>
<artifactId>suitetalk-axis-proxy-v2019_1</artifactId>
<version>1.0.0</version>
<packaging>jar</packaging>
<generatePom>true</generatePom>
</configuration>
<goals>
<goal>install-file</goal>
</goals>
</execution>
<execution>
<id>suitetalk-client</id>
<phase>clean</phase>
<configuration>
<file>${basedir}/lib/suitetalk-client-v2019_1-2.0.0.jar</file>
<repositoryLayout>default</repositoryLayout>
<groupId>com.netsuite.suitetalk.client.v2019_1</groupId>
<artifactId>suitetalk-client-v2019_1</artifactId>
<version>2.0.0</version>
<packaging>jar</packaging>
<generatePom>true</generatePom>
</configuration>
<goals>
<goal>install-file</goal>
</goals>
</execution>
<execution>
<id>suitetalk-client-common</id>
<phase>clean</phase>
<configuration>
<file>${basedir}/lib/suitetalk-client-common-1.0.0.jar</file>
<repositoryLayout>default</repositoryLayout>
<groupId>com.netsuite.suitetalk.client.common</groupId>
<artifactId>suitetalk-client-common</artifactId>
<version>1.0.0</version>
<packaging>jar</packaging>
<generatePom>true</generatePom>
</configuration>
<goals>
<goal>install-file</goal>
</goals>
</execution>
</executions>
</plugin>
I am including 3 jars from lib folder:
Finally, use mvn clean and then mvn install or 'mvn clean install' and just run jar file from target folder or the path where install(see mvn install log):
java -jar abc.jar
note: Remember one thing if you are working at jenkins then first use mvn clean and then mvn clean install command work for you because with previous code mvn clean install command store cache for dependency.
Following this thread I was able to configure the install plugin to load my custom jar, but the plugin was not seeing my configuration when running a mvn install
I'm using the base maven-install-plugin:2.5.2 using the maven:3.6.3-jdk-8 docker image.
I don't fully understand this note in the documentation (at the end of the section), but it seems that you can give the phase goal an execution id forcing it to use your configuration:
Note: Configurations inside the element used to differ from those that are outside in that they could not be used from a direct command line invocation because they were only applied when the lifecycle phase they were bound to was invoked. So you had to move a configuration section outside of the executions section to apply it globally to all invocations of the plugin. Since Maven 3.3.1 this is not the case anymore as you can specify on the command line the execution id for direct plugin goal invocation. Hence if you want to run the above plugin and it's specific execution1's configuration from the command-line, you can execute:
mvn myqyeryplugin:queryMojo#execution1
My final working docker command:
docker run -it --rm --name parser -v "$(shell pwd)":/usr/src/parser -w /usr/src/parser maven:3.6.3-jdk-8 mvn -X install:install-file#install-my-jar-file
Where install-my-jar-file is my executions id <execution><id>install-my-jar-file</id>...