Since last few days a lot of doubts got cleared because of the you all experts. I have one more question, when i see my pom.xml in my project , I see a lot of plugins with quite a few configuration. for e.g
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>3.0.0-M4</version>
<dependencies>
<dependency>
<groupId>org.apache.maven.surefire</groupId>
<artifactId>surefire-junit-platform</artifactId>
<version>3.0.0-M4</version>
</dependency>
</dependencies>
<configuration>
<forkCount>1</forkCount>
<reuseForks>true</reuseForks>
<argLine>${argLine} -Xmx4g -XX:MaxPermSize=1g</argLine>
<includes>
<include>**/*Test.java</include>
<include>**/*Spec.java</include>
</includes>
</configuration>
</plugin>
My question is how they decided the these forkcount , argLine needed to be used here? plus the dependency also. When i checked the bealdung doc for same plugin the config was very simple. is it necessary to read docs for a perticular plugin before using it. like how people take decisions for the same that what are the tags to be used or what are the mandatory tags. any links will be helpful.
Thanks
I strongly recommend reading the docs of the appropriate plugin which would show like in your example defining the provider (the dependency) https://maven.apache.org/surefire/maven-surefire-plugin/examples/providers.html is usually not needed nor helpful/useful. For the other settings it depends on what kind of tests you are running but from my point of view I would strongly review my tests because needed to set 4 GiB for heapspace sounds weird .... especially for a tests? The others parts depends on the testing framework you are using.. and your use case. I usually start without any configuration for my builds ...only If i really need to change something I do so which is rarely the case. (Convention over configuration)... and read the docs: https://maven.apache.org/surefire/maven-surefire-plugin/plugin-info.html
Related
I would like to use maven filtering, in my src/main/liberty/config/server.xml without breaking the use of liberty:dev from the maven-liberty-plugin. My biggest problem seems to be that the liberty-maven-plugin does not honor filtering.
For example, consider this webApplication element:
<webApplication id="${project.artifactId}" contextRoot="/"
location="${server.config.dir}/apps/${project.artifactId}.war">
</webApplication>
Without any other guidance, this file is copied to target/liberty/wlp/usr/servers/defaultServer/server.xml without any filtering, so the runtime cannot find the WAR file.
Let's say I manually turn on the filtering using maven-resources-plugin:
<plugin>
<artifactId>maven-resources-plugin</artifactId>
<version>3.2.0</version>
<executions>
<execution>
<id>01-liberty-config</id>
<phase>package</phase>
<goals>
<goal>copy-resources</goal>
</goals>
<configuration>
<outputDirectory>${project.build.directory}/liberty/wlp/usr/servers/defaultServer</outputDirectory>
<resources>
<resource>
<directory>src/main/liberty/config</directory>
<filtering>true</filtering>
</resource>
</resources>
</configuration>
</execution>
</executions>
</plugin>
Now the filtering works and the file is in the correct location. Unfortunately, I observe that when I run mvn liberty:dev, this gets overwritten by the unfiltered server.xml from src/main/liberty/config/server.xml.
Is it possible to use maven filtering in a server.xml?
BACKGROUND
This is essentially not supported today. The liberty-maven-plugin doesn't let you do this, and the way in which the liberty-maven-plugin manages and controls the Liberty config also doesn't make it easy for you to use standard Maven plugins like 'dependency' or 'resources' plugin either.
Since this issue was raised before I shared a sample approach which you might find useful, though it has the feel of a workaround.
SOLUTION OVERVIEW
Basically, although although we can't substitute into server.xml itself via filters we can substitute into a config snippet that gets included by server.xml, and copy this into place using the resources plugin, rather than liberty-maven-plugin.
SOLUTION DETAIL
Say I wanted to use a "filter"-style Maven variable substitution ${tidal.url} for a URL in Liberty server config.
1. src/main/filtered-config/environment.xml
First define a config snippet, which we are going to apply the filter to.
<server description="environment">
<!-- Expect to come from filter -->
<variable name="tidal.url" value="${tidal.url}"/>
</server>
2. pom.xml
Configure an execution of resources:copy-resources copying the "environment.xml" snippet above to the shared config dir location, target/liberty/wlp/usr/shared/config, with filtering enabled:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-resources-plugin</artifactId>
<version>3.2.0</version>
<executions>
<execution>
<id>default-cli</id>
<phase>none</phase>
<goals>
<goal>copy-resources</goal>
</goals>
<configuration>
<overwrite>true</overwrite>
<!-- This location can persist across a server recreate, where the refresh can annoyingly wipe out your earlier copy -->
<outputDirectory>target/liberty/wlp/usr/shared/config</outputDirectory>
<resources>
<resource>
<directory>src/main/filtered-config</directory>
<filtering>true</filtering>
</resource>
</resources>
</configuration>
</execution>
</executions>
</plugin>
3. server.xml
In your main server.xml config file, add an <include> of the config snippet you copied into the shared config dir via "copy-resources".
Also shown is how we finally use or "consume" the value applied via the filter, here in this <jndiEntry>, in this sample:
<include location="${shared.config.dir}/environment.xml"/>
<!-- This is how I'm ultimately going to "consume" the filtered value -->
<jndiEntry jndiName="url/tidal-api" value="${tidal.url}" id="TidalJNDI" />
4. Run dev mode, invoking the extra goal first, and activating your filter somehow
E.g.:
mvn resources:copy-resources liberty:dev
As far as activating your filter, maybe you have a filter defined in your build (via build.filters.filter like in my sample repo) or maybe you're just using -Dtidal.url=<value>.
FOLLOW-UP
Besides being complicated a significant limitation of the above is that you only get a single chance to apply the filter. You cannot iterate through different values in a single dev mode "session".
Feel free to give feedback on the issue: https://github.com/OpenLiberty/ci.maven/issues/587
Also I will note we are considering enhancing filter support for general resources and web resources here.
ONE MORE THOUGHT
If all you need is a dynamic way to select, at build time, one set of Liberty config values vs. another you don't necessarily need to use filtering.
You could instead use the support which maps Maven properties to Liberty config.
E.g. for this example you could have one profile which defines
<properties>
<liberty.var.tidal.url>URL1</liberty.var.tidal.url>
</properties>
and another profile defining the same property with a different value.
This would parameterize my sample:
<jndiEntry jndiName="url/tidal-api" value="${tidal.url}" id="TidalJNDI" />
just fine.
The problem though is if you wanted to use the same sets of properties in other contexts with other plugins that did fully support filtering. Then, you want standard Maven filtering.
I'm trying to exclude some packages from the Jacoco coverage scan, but it's not working like how I would expect. Here's my Maven POM configuration for Jacoco:
<plugin>
<groupId>org.jacoco</groupId>
<artifactId>jacoco-maven-plugin</artifactId>
<version>0.8.0</version>
<configuration>
<excludes>
<exclude>**/pojo/**/*</exclude>
</excludes>
</configuration>
</plugin>
The behavior I'm experiencing is that the files are being set to 0% lines covered instead of reducing the total lines to cover, which is actually reducing my coverage percentage. So how do I correct this?
EDIT: A workaround for this issue is to remove the file entirely from SonarQube using sonar properties:
<sonar.exclusions>**/pojo/**/*</sonar.exclusions>
However, this is just a workaround since now I can't see code smells from those files (there probably aren't any since they are POJOs, but I like the sense of security of knowing for a fact there are no code smells).
Total lines of code in Sonar are not totally managed by Jacoco. You need to add this property to your pom.xml:
<properties>
<sonar.coverage.exclusions>**/pojo/**/*</sonar.coverage.exclusions>
</properties>
I am using maven 3.0.4 and would like to make the build timestamp accessible to my application. For this, I'm putting a placeholder in a .properties file and let maven filter on build. While this is working fine for ${project.version}, ${maven.build.timestamp} is not substituted on filtering.
The property seems to be available on build - I can use it to modify the artifact name:
<finalName>${project.artifactId}-${maven.build.timestamp}</finalName>
So why is it not available for resource filtering? And, more importantly, how do I make it accessible?
I have discovered this article, explaining that due to a bug in maven, the build timestamp does not get propagated to the filtering. The workaround is to wrap the timestamp in another property:
<properties>
<timestamp>${maven.build.timestamp}</timestamp>
<maven.build.timestamp.format>yyyy-MM-dd HH:mm</maven.build.timestamp.format>
</properties>
Filtering then works as expected for
buildTimestamp=${timestamp}
I can confirm as of Maven 3.x {maven.build.timestamp} is "working" now. They work arounded the problem, apparently. No additional properties workaround needed anymore.
However, be careful your "filtering" plugin (maven-resources-plugin) is up to date. It needs to be relatively new, so if mvn help:effective-pom shows an old version (ex: 2.6), bump it to something newer, fixed it for me, 3.x ex:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-resources-plugin</artifactId>
<version>3.1.0</version>
</plugin>
<properties><timestamp>... workaround is no longer required...
This also cleared up, kind of, why it was working in IntelliJ but not the command line. IntelliJ probably uses their own "modified/internal" maven constants, so it was working there, but not from maven command line.
Also note if you add a filtering resource directory to you pom, you may need to also "re-add" the default directory, it gets lost, ex:
<resource>
<directory>src/main/resources-filtered</directory> <!-- to get "maven.build.timestamp" into resource properties file -->
<filtering>true</filtering>
</resource>
<resource>
<directory>src/main/resources</directory> <!-- apparently have to add this is you have the other... -->
</resource>
NB if you're using spring boot as your parent, you have to use #maven.build.timestamp# instead. Also note if you're using spring boot there's a file META-INF/build-info.properties that is optionally created by the spring-boot-maven-plugin that you can read (spring provides a BuildProperties bean for convenience reading it).
In order to enrich the Stackoverflow content for others, that like me, found this post as a way to solve the "problem" of ${maven.build.timestamp}. This is not a maven bug, but an expected behavior of m2e, as can be seen in this post.
Therefore, I believe that we can not expect the solution to be "corrected", since, from what I understand, the correction involves conceptual issues.
In my case, what I did was use the plugin (buildnumber-maven-plugin) as described in this other post.
Adding Maven properties at the pom project level doesn't take into account correct local Timezone, so timestamp may appear wrong :
<properties><timestamp>${maven.build.timestamp}</timestamp></properties>
Using the build-helper-maven-plugin applies the correct timezone and current daylight saving to the timestamp :
<build>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>build-helper-maven-plugin</artifactId>
<version>1.9.1</version>
<executions>
<execution>
<id>timestamp-property</id>
<goals>
<goal>timestamp-property</goal>
</goals>
<configuration>
<name>timestamp</name>
<pattern>yyyy-MM-dd HH:mm:ss</pattern>
<timeZone>Europe/Zurich</timeZone>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
<resources>
<resource>
<directory>src/main/resources</directory>
<filtering>true</filtering>
</resource>
</resources>
</build>
When packaging, Maven will replace any token timestamp in /resources folder, e.g. resources/version.properties :
build.timestamp=${timestamp}
You can then load this properties file in your Application.
http://svn.apache.org/repos/asf/felix/releases/maven-bundle-plugin-2.3.7/doc/site/wrap-mojo.html says bundle:wrap is deprecated, same with bundle:bundleall. I currently use wrap to create an OSGi bundle from a non-OSGi dependency, as described at http://www.lucamasini.net/Home/osgi-with-felix/creating-osgi-bundles-of-your-maven-dependencies. What should they be replaced by and what's the reason for the deprecation?
The alternative is to just use the bundle:bundle goal, then in your pom.xml configure the plugin similar to the following:
<plugin>
<groupId>org.apache.felix</groupId>
<artifactId>maven-bundle-plugin</artifactId>
<configuration>
<instructions>
<Embed-Dependency>*;scope=compile;inline=true</Embed-Dependency>
<_exportcontents>*</_exportcontents>
</instructions>
</configuration>
</plugin>
You can control what dependencies get embeded and exported by changing the wildcards "*", scope, etc. attributes.
I've wondered the same question, found some clue here:
http://www.mail-archive.com/dev#felix.apache.org/msg22221.html
"Instead new features/goals will be added to solve common use-cases such as
creating mega-bundles, etc."
I guess they're going to rework the current goals because the current codebase doesn't support all that they want to implement in the plugin.
We've been experiencing problems with jsessionid and I'm trying to figure out a way to disable this. Would anybody happen to know how you can do this using the org.mortbay.jetty:jetty-maven-plugin:7.x.x? So far, all I've come across are ways to do it using the old plugin from Mortbay whose settings are incompatible with Eclipse's version.
Thanks in advance,
Martin
Submitting answer to my own question due to the fact that nobody seems to have an answer for this and I am sure someone else will eventually find it useful as well, because all the other examples of how to do this were for the old maven-jetty-plugin (<7.x).
After digging through Jetty's code for a while, I found out that the variable had been renamed as shown below:
<build>
<plugins>
<plugin>
<groupId>org.mortbay.jetty</groupId>
<artifactId>jetty-maven-plugin</artifactId>
<version>${version.jetty}</version>
<configuration>
<webAppConfig>
<contextPath>/foo</contextPath>
<sessionHandler implementation="org.eclipse.jetty.server.session.SessionHandler">
<sessionManager implementation="org.eclipse.jetty.server.session.HashSessionManager">
<!-- Disable url sessions using JSessionID -->
<sessionIdPathParameterName>none</sessionIdPathParameterName>
</sessionManager>
</sessionHandler>
</webAppConfig>
</configuration>
</plugin>
<plugins>
</build>