It is interesting, if we have a plugin with configuration parameter named "fooParameter".
And we specify it twice: one in global configuration and the other in local configuration under execution section.
When we are execution test pahes what will take precedence global or local configuration?
<plugin>
<groupId>com.myplugin</groupId>
<artifactId>com.myplugin</artifactId>
<version>1.0</version>
<configuration>
<fooParameter>10</fooParameter>
</configuration>
<executions>
<execution>
<id>myExecution</id>
<phase>test</test>
<configuration>
<fooParameter>20</fooParameter>
</configuration>
</execution>
</executions>
</plugin>
The answer is the following:
take precedence local configuration
I.e. if we type
mvn package
we get fooParameter=20
Related
I've managed to convert my "war" application to a hollow jar.
My biggest issue is that even after following the documentation, still cannot enable debug mode (my desired port is 8784)
I am pretty sure that I am missing something but ... what?
<plugin>
<groupId>org.wildfly.swarm</groupId>
<artifactId>wildfly-swarm-plugin</artifactId>
<version>${wildfly-swarm.version}</version>
<executions>
<execution>
<id>package</id>
<goals>
<goal>package</goal>
</goals>
<configuration>
<hollow>true</hollow>
<properties>
<swarm.debug.port>8784</swarm.debug.port>
<debug.port>8784</debug.port>
<swarm.debug.bootstrap>true</swarm.debug.bootstrap>
<java.net.preferIPv4Stack>true</java.net.preferIPv4Stack>
</properties>
</configuration>
</execution>
</executions>
</plugin>
The swarm.sebug.port property is only relevant when starting the application via the Swarm Maven plugin, or when using the Swarm Arquillian adapter. When starting the application using java -jar myapp-swarm.jar, you need to use the standard Java way of enabling remote debugging, i.e. something like java -Xdebug -agentlib:jdwp=transport=dt_socket,address=8784,server=y,suspend=n -jar myapp-swarm.jar.
You may want to look into:
https://issues.jboss.org/browse/THORN-1321
or
https://intellij-support.jetbrains.com/hc/en-us/community/posts/206848015-Breakpoints-not-working-when-debugging-simple-Java-EE-app-on-wildfly?page=1#community_comment_360000176459
The first link is the relevant one. I am including the second one just for further information if you are using IntelliJ for IDE.
Briefly, here is my pom configuration:
<plugin>
<groupId>org.wildfly.swarm</groupId>
<artifactId>wildfly-swarm-plugin</artifactId>
<version>${version.wildfly.swarm}</version>
<executions>
<execution>
<goals>
<goal>package</goal>
</goals>
</execution>
</executions>
<configuration>
<debugPort>5005</debugPort>
<properties>
<swarm.debug.port>5005</swarm.debug.port>
</properties>
</configuration>
</plugin>
After starting the application with the mvn swarm plugin, I am connecting with a remote debugger.
Good luck!
Edit (2019.05.31):
My current setup for debugging in the pom.xml is the following:
<plugin>
<groupId>org.wildfly.swarm</groupId>
<artifactId>wildfly-swarm-plugin</artifactId>
<version>${version.wildfly.swarm}</version>
<executions>
<execution>
<goals>
<goal>package</goal>
</goals>
</execution>
</executions>
<configuration>
<jvmArguments>
<jvmArgument>-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=5005</jvmArgument>
</jvmArguments>
</configuration>
</plugin>
For some reason my client needs my artifacts without version in their names (MyArtifact.jar instead of MyArtifact-1.23.345.jar)
Therefor I added this configuration to my parent pom:
<build>
<pluginManagement>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<version>3.0.2</version>
<configuration>
<finalName>${project.artifactId}</finalName>
</configuration>
</plugin>
</plugins>
</pluginManagement>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
</plugin>
</plugins>
</build>
This works as expected, meaning that I get jars of the child projects without versions generated in target folder.
However.
One of my jars is an executable jar which depends on the others. Currently I have the maven-jar-plugin configured for that subproject:
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<version>2.7</version>
<executions>
<execution>
<phase>compile</phase>
<goals>
<goal>build-classpath</goal>
</goals>
</execution>
</executions>
<configuration>
<fileSeparator>/</fileSeparator>
<pathSeparator>;</pathSeparator>
<outputProperty>bundle.classPath</outputProperty>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<configuration>
<archive>
<index>true</index>
<manifestEntries>
<Class-Path>${bundle.classPath}</Class-Path>
</manifestEntries>
</archive>
<finalName>${project.artifactId}</finalName>
</configuration>
</plugin>
</plugins>
</build>
The problem is that this generated classpath contains absolute paths to the artifacts on my PC.
Therefore I added the <prefix> tag to the configuration:
<configuration>
<prefix>lib</prefix>
<fileSeparator>/</fileSeparator>
<pathSeparator>;</pathSeparator>
<outputProperty>bundle.classPath</outputProperty>
</configuration>
But then the generated classpath includes the version numbers of the jars.
How can I omit the version numbers and the absolute paths in the classpath?
Problem is: I only want to remove Version numbers from my own artifacts, not from third party libs.
To remove the version from copied dependencies, you can use the stripVersion option of the maven-dependency-plugin.
In the aggregator pom use the dependency:copy-dependencies to copy your jars to some intermediate location.
For you internal dependencies use <stripVersion>true</stripVersion>.
For you 3rd party libraries use <stripVersion>false</stripVersion>.
You may in-/exclude artifacts based on the group id.
For more detail you may look here.
EDIT:
This is to explain how the finalname works.
finalName: This is the name of the bundled project when it is finally built
(sans the file extension, for example: my-project-1.0.jar). It defaults to
${artifactId}-${version}. The term "finalName" is kind of a misnomer,
however, as plugins that build the bundled project have every right to
ignore/modify this name (but they usually do NOT). For example, if the
maven-jar-plugin is configured to give a jar a classifier of test, then the
actual jar defined above will be built as my-project-1.0-test.jar.
Basically it includes almost always the version in your .jar.
In the version (2.6 >), in the <configuration> it allows you to specify the <fileNameMapping>no-version</fileNameMapping>.
The jar plugin alone is able to compute and write the manifest classpath.
This produces a working jar with the desired name
<build>
<finalName>${project.artifactId}</finalName>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<version>2.4</version>
<configuration>
<archive>
<index>true</index>
<manifest>
<addClasspath>true</addClasspath>
<classpathPrefix>lib/</classpathPrefix>
</manifest>
</archive>
</configuration>
</plugin>
</plugins>
</build>
I defined the following pom.xml file for generating of reports during an integration testing.
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-report-plugin</artifactId>
<version>2.19</version>
<configuration>
<aggregate>true</aggregate>
</configuration>
<executions>
<execution>
<phase>verify</phase>
<goals>
<goal>report</goal>
</goals>
</execution>
</executions>
</plugin>
If the mvn verify is executed,there are no reports created. I have to use mvn surefire-report:report for generating.
The above mentioned pom.xml file is parent for two children to be clear.
Does anyone know what is wrong?
Actually the above solution works just only if it is defined in child pom.xml file. It does not work in parent one. Is it bug or what is going on? I spent several hours when I got it!
I need to execute the same maven plugin more than once in the same phase.
What I want:
Execute maven-assembly-plugin
Execute myplugin (depends on step 1)
Execute maven-assembly-plugin again (depends on step 2)
Execute myplugin again (depends on step 3)
Execution order when I define the plugins sequentially (same order as above):
Execute maven-assembly-plugin
Execute maven-assembly-plugin again
Execute myplugin
Execute myplugin again
My solution is to combine all executions in my own plugin to control the exact order, but I don't think it's the best way to do it. Thanks !
Do you absolutely have to run the plugins during the same exact phase? Can't you use some other related phase? Maven has a lot of phases nowadays :) e.g. "prepare-package" vs. "package". I would probably try to define multiple executions for the plugin like this (bwt this is not a real-world scenario):
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-assembly-plugin</artifactId>
<version>2.2.1</version>
<executions>
<execution>
<id>assembly1</id>
<goals>
<goal>assembly</goal>
</goals>
<phase>prepare-package</phase>
<configuration>
<descriptorRefs>
<descriptorRef>jar-with-dependencies</descriptorRef>
</descriptorRefs>
</configuration>
</execution>
<execution>
<id>assembly2</id>
<goals>
<goal>assembly</goal>
</goals>
<phase>package</phase>
<configuration>
<descriptorRefs>
<descriptorRef>jar-with-dependencies</descriptorRef>
</descriptorRefs>
</configuration>
</execution>
</executions>
</plugin>
Not sure if it will work for your desired order though. Might be worth a try.
Here is what my build plug in stanza looks like:
<plugin>
<groupId>com.pyx4me</groupId>
<artifactId>proguard-maven-plugin</artifactId>
<version>2.0.4</version>
<executions>
<execution>
<phase>package</phase>
<goals>
<goal>proguard</goal>
</goals>
</execution>
</executions>
<configuration>
<options>
<option>-dontshrink</option>
<option>-dontnote</option>
<option>-allowaccessmodification</option>
<option>-dontskipnonpubliclibraryclasses</option>
<option>-dontskipnonpubliclibraryclassmembers</option>
</options>
<libs>
<lib>${java.home}/lib/rt.jar</lib>
<lib>${java.home}/lib/jsse.jar</lib>
</libs>
</configuration>
</plugin>
Here is what I get from execution of mvn clean package
[proguard] Error: You have to specify '-keep' options for the shrinking step.
How do I specify the keep options for a library where I just want obfuscation?
You must define with the -keep option the entry points of your application, because you can't obfuscate it. For example if your main class is obfuscated it will be renamed and you won't be able to launch it. The same for public interfaces of your APIs.