I'm trying to use async-profiler with maven, sadly it does not track forked processes and my tests need the isolation provided by forks to run correctly.
In order to run async-profiler I need to run java with this parameter:
-agentpath:/path/to/libasyncProfiler.so=start,svg,file=profile.svg
I was thinking using surefire's argLine, but it would erase profile.svg each time.
I was thinking using the project's artifactId do parameterized it, but I found no reference on that.
How can get the artifactId on the tested project in the argLine field?
Thanks by advance.
See Introduction to the POM, Project Model Variables:
Any field of the model that is a single value element can be referenced as a variable.
For your case it's ${project.artifactId}. Use this in Surefire configuration's <argLine>.
Related
I'd like to externalize the dependency versions in the POM file to a properties file.
Example: pom.xml
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>${externalized.junit.version}</version>
</dependency>
abc.properties
externalized.junit.version=4.8.2
Can this be done? If so, what would be the best way to do it?
No, you cannot do that.
When you're launching a Maven command on a project, the first action it takes is creating the effective model of the project. This notably means reading your POM file, reasoning with activated profiles, applying inheritance, performing interpolation on properties... all of this to build the final Maven model. This work is done by the Maven Model Builder component, whose entry point is the ModelBuilder interface, and exit point is the Model class.
The process of building the model is quite complicated, with a lot of steps divided in possibly 2 phases, but the crux of the issue here is simple: at the end of that step, there is a valid effective model to be used by Maven. Which means that all dependencies must have valid group ids, artifact ids, versions; that there are no duplicate dependencies, no plugin execution's with the same ids, etc. (refer to the model description).
Take note that during the model building, interpolation is happening, meaning that if a property is available at that time, and it was used, like ${myProperty}, then it will be replaced with its corresponding value. Among the properties available are:
POM content, like ${project.version} or ${project.artifactId};
${project.basedir}, which corresponds to the directory where the pom.xml is;
user properties set on the command line with the -D switch (like -DmyProperty=myValue);
any properties set directly in the POM file, inside the <properties> element;
several built-in Maven properties, like ${maven.build.timestamp}, which represents the date/time at which the build started, or ${maven.version} for the current Maven version;
Java system properties, as returned by System.getProperties()
environment variables;
and finally properties set inside the settings.xml file.
The critical point point here, is that the version of dependencies must be valid when the effective model is built. This is the only way to make sure the dependency graph is stable and consistent during the build.
This is exactly what is failing here: you would want Maven to be able to read versions inside a properties file, so it means binding a plugin to a specific phase of the lifecycle to read that file and somehow refer to the properties read using a standard Maven properties. Trouble is, this would all be happening after the model is already built, so it is too late for that. All of this process is happening before the build lifecycle has even started; no chance to invoke a plugin before that.
This also implies that it would work if you were to define the property as a command-line property (since, as outlined above, it is available during the interpolation process when building the model). But that is not a best practice: specifying dependency version as a command-line property makes the build very hard to reproduce. Better to specify it as a Maven property inside the <properties> element of the POM, or to make use of the <dependencyManagement> scheme in a parent POM or also importing a BOM.
If you really need something like this, the easiest way would be to write a shell script (or some other short command line program) that copies the pom, replaces the specified properties in the pom and calls maven.
But as was said before: Probably there are more Maven-like ways to achieve what you want to achieve.
I want to save maven information in my database like the version of my project in each run of liquibase.
I try to put my maven variable in an external properties file but it's not taken and my value is "{project.version}" in my table.
There is a way to get this information ?
Thanks for your help.
You need to check out what Maven resource filtering is.
When you define <resource/>-s in your pom.xml, you can turn on filtering, by doing <filtering>true</filtering>. This will tell Maven to replace all ${foo.bar}-like variables in your resources.
I use different maven plugins to resolve properties from a file (properties-maven-plugin) and manipulate them during the life-cycle (gmaven-plugin).
In the end (at deploy) I would like to have all those properties visible in the output pom, but so far I haven't found out how to do that.
Does the maven-help-plugin would help you ?
mvn help:effective-pom
http://maven.apache.org/plugins/maven-help-plugin/usage.html
You would see the effective pom but without any comments, so you won't be able to persist it.
As far as I know, what you require does not exist.
How can I make maven do a site:site and a site:deploy when the deploy is run?
Am I best off to make my own plugin (modified version of maven-release-plugin) or is there an easy way in Maven (configuration of a plugin within a profile)?
Thanks!
EDIT for clarification: I basically want a site-deploy done (to a special url) for snapshot releases. Namely the javadoc. Thanks!
Create two profiles.
The first will be active unless a property has been defined. It will use one URL.
The second one will be triggered by some property.
In each profile define the required settings for the site plugin with their respective differences.
We are using Maven(3.0.3) as build tool and we need to have different version for different environments (DEV , TEST, QA ) . If we pass version property value during build time based on environment , the installed POM doesn't have the passed property values instead it still has the ${app-version} string.
I saw already there is a bug for this http://jira.codehaus.org/browse/MNG-2971
Is there any other alternative ,because we cannot different POM file for different environments ,which will be hard to maintain..
Thanks
Vijay
Create different artifacts for the environments and use the parameter as a classifier. The pom is the same for all three artifacts but the classifier separates them.
Apparently Maven does not make any variable/property substitution when installing the POM. It is installed as is, that is the principle. You'd better not read any properties from POM (unless this is e.g. version number), bout you should configure your properties in external file (one per stage, e.g. dev.properties, test.properties, ...) and then configure Maven profiles (again, one per stage) and invoke Maven like mvn -Pdev depending on what you want to build. In profile you can package your final application with whatever properties you like (e.g. with the help of build-helper-maven-plugin:add-resource or maven-antrun-plugin + copy rule).
Alternatively you can filter your resources. For example, you can filter your Spring context XML file, which refers the properties file (so you package all property files, but Spring will refer only some specific). Or you can filter another properties file from which you will learn what is the "main" properties file to use (double indirection).
You should create the archives for your different targets within a single build and use as already mentioned the classifier to separate those artifacts from each others.