Is this possible? I need to be able to use Maven to download a dependency to a specific directory and unpack it there, not knowing the version number. I can get close, with maven-dependency-plugin:2.7:get providing the "dest" param and using "LATEST" in the artifact param. It gets the resource (a tarball) downloaded to where I want it. But now I'd like maven to also extract it.
So since versions newer than 2.7 recommend using maven-dependency-plugin:copy if I need the dest param, I thought I could use maven-dependency-plugin:unpack (the same as copy, but unpacks the dependency in the process). However, both copy and unpack require the artifact have a version number, so I'm stuck.
Also tried using maven-dependency-plugin:get with no dest, then maven-dependency-plugin:unpack-dependencies in the same command, but seems unpack-dependencies requires a pom file to work. Bummer.
Is there a way to get the version number of the latest and somehow make it used in the unpack command, without any sort of bash trickery (stuck using just mvn commands)?
For unpacking, try this:
<plugin>
<artifactId>maven-antrun-plugin</artifactId>
<version>1.7</version>
<executions>
<execution>
<phase>package</phase>
<id>Unpack</id>
<configuration>
<target>
<untar src="some_dependency_*.tar" dest="${proj.home}"/>
</target>
</execution>
</executions>
</plugin>
Related
I have read that the ${project.version} property should be used to obtain the full version of a project.
But if I use this property in a build to pass the currently built version to an external build process, its values is alway 1.0.0-SNAPSHOT where I would need something like 1.0.0-20160220-1234. The phase in which the external build step is called is `package´.
The tycho-packaging-plugin is configured to produce timestamps like this:
<configuration>
<format>yyyyMMdd-HHmm</format>
</configuration>
And the resulting artifacts do have timestamps in the versions/names
I use Maven 3.3.3 with Eclipse Tycho 0.24, however, with previous versions of Tycho the behavior is the same. Not sure if Tycho behaves differently than plain Maven in this regard.
The build is run with
mvn clean verify
in the directory of the master pom.
The actual project I am using this for is Extras for Eclipse. The external build step is invoked in line 129 of the 'repository' child pom.
I have also used the echo plug-in in the above-mentioned child pom to diagnose the problem like this:
<plugin>
<groupId>com.soebes.maven.plugins</groupId>
<artifactId>maven-echo-plugin</artifactId>
<version>0.1</version>
<executions>
<execution>
<phase>package</phase>
<goals>
<goal>echo</goal>
</goals>
</execution>
</executions>
<configuration>
<echos>
<echo>actual version: ${project.version}</echo>
</echos>
</configuration>
</plugin>
The output is the same as the external build receives: 1.0.0-SNAPSHOT.
What do I need to do or which property do I need to use to get the qualified version of the current build?
From my understanding the ${project.version} property should hold the qualified version, e.g. 1.0.0-20160218-1234. But either there is a bug in Maven/Tycho or my understanding is plain wrong. And I would be happy if someone could clarify this.
However, I found the ${qualifiedVersion} property that is set by the tycho-packaging:build-qualifier mojo. This property holds the expected value.
Note that even though the documentation states
is assigned to the project property qualifiedVersion
the property cannot be accessed through ${project.qualifiedVersion}. It needs to be referenced as ${qualifiedVersion}.
I'm using Tycho extras to mirror repositories using a target file. The thing is in my .target file I have some installable units with version 0.0.0 meaning I want to get the latest version, but what if I want to run a script to freeze the version, I mean getting the latest one available now and explicitly put the number in the .target file so in the future I'll still mirror the same version I have now.
<plugin>
<groupId>org.jboss.tools.tycho-plugins</groupId>
<artifactId>target-platform-utils</artifactId>
<version>0.21.0</version>
<executions>
<execution>
<phase>compile</phase>
<goals>
<goal>mirror-target-to-repo</goal>
</goals>
</execution>
</executions>
<configuration>
<sourceTargetFile>${target-platform-file}</sourceTargetFile>
<includeSources>false</includeSources>
<outputRepository>${basedir}/target/repository</outputRepository>
</configuration>
</plugin>
There is a dedicated plug-in for this task, which you can call from the command line:
mvn org.eclipse.tycho.extras:tycho-version-bump-plugin:0.22.0:update-target -Dtarget=path/to/targetfile.target
This command needs a Maven/Tycho project, so you need to start it in the directory of your parent pom.xml (or specify the path to that file with -f). Also, the version number in the command needs to match the Tycho version configured in your project.
Also note that the command updates all artifact versions to the latest available version, not only the ones which had a 0.0.0 version literal. If you just want to update some versions, keep a backup of your target file and then pick the changes you want with a diff tool of your choice.
I want to use svn revision number of pom file as its version.
In pom.xml, if we use buildnumber-maven-plugin, we need to define scm repository url, so that it can check to repository and use buildnumber.
But i want to ask that when we have checkedout code to our system, isn't there any way to get buildnumber without using scm urls. As revision number is stored as subversion in property of each file. we can see it if we right click on file and go to properties.
I want to use buildnumber in version tag of pom and other module's buildnumber in their vaersion tag in dependencies to them.
So if i can store all subversion numbers initially, infact earlier than resolving dependencies, then these subversions can be placed in version of module in dependency and also in version of each pom file.
Problem is that dependencies are resolved before plugin reads version number ( this is what i think), so it cannot resolve expression.
I tried it using properties-maven-plugin to write pom's version number in a file and then read it in other module's pom which is dependent on it. But dependencies are to be resolved before execution of any plugin is started.
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>properties-maven-plugin</artifactId>
<version>1.0-alpha-2</version>
<executions>
<execution>
<id>pre-clean-config</id>
<phase>validate</phase>
<goals>
<goal>read-project-properties</goal>
</goals>
<configuration>
<files>
<file>${project.basedir}/../app.properties</file>
</files>
</configuration>
</execution>
</executions>
</plugin>
So, it is not working.
Starting with Maven 3.2.1 you can define a property ${revision} which you can use in your versions like this:
<project...>
<groupId>..</groupId>
<artifactId>...</artifactId>
<version>1.0-${revision}</version>
...
The result of this you need to give a property while calling Maven like this:
mvn -Drevision=123456 clean package
This will also work in dependencies etc. Currently one drawback is that you always creating a release from maven's point of view.
When this plugin is attached to the test or package phase, it causes a multi module build to break since it forces dependency resolution before the module dependencies are in the local repository (first build upon updating to a new snapshot version). I'm trying to get the plugin to ignore the offending com.cons3rt group dependencies which are not required for license output. Tried several variations of:
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>license-maven-plugin</artifactId>
<version>1.3</version>
<executions>
<execution>
<id>aggregate-add-third-party</id>
<configuration>
<excludedGroups>com.cons3rt</excludedGroups>
</configuration>
<phase>package</phase>
<goals>
<goal>aggregate-add-third-party</goal>
</goals>
</execution>
</executions>
Nothing seems to work - looking at the output of mvn -X, it seems like the plugin is not honoring the configuration setting for excludedGroups. Anyone have any luck using this configuration approach?
In your configuration use a pipe to separate multiple groupIds and set the .* to refer to all sub packages:
<excludedGroups>com.group1.*|com.group2.*</excludedGroups>
A workaround for this problem is to pass the parameter through the command line using the
-Dlicense.excludedGroups
parameter.
e.g. mvn package -Dlicense.excludedGroups=com.jhla.*
Simply Change
<excludedGroups>com.cons3rt</excludedGroups>
to
<excludedGroups>^com\.cons3rt</excludedGroups>
as the given string needs to be a regular expression.
For further information, see documentation at:
http://www.mojohaus.org/license-maven-plugin/aggregate-add-third-party-mojo.html
I'm working with a situation where we are using the LATEST and RELEASE keywords in our POM for a certain dependency (both the dependency and the project are owned by us, so we control what is LATEST and RELEASE...and we only support one version at a time). Using these keywords allows us to minimize maintenance needed after a release.
There is a step in the build process that must copy DLLs from the unpacked dependency, but since we don't specify a specific version we have the version number of the unpacked dependency hard-coded and have to update it after every release. Is there a way get the version of this dependency at run-time from a Maven property?
The properties goal of the maven-dependency-plugin (http://maven.apache.org/plugins/maven-dependency-plugin/index.html) gets the location of the artifact in the local repository (which is not what I'm looking for). The depends-maven-plugin (shown here: http://team.ops4j.org/wiki/display/paxexam/Pax+Exam+-+Tutorial+1) can generate a file that contains the various dependencies and their versions, but using that would require having a process read the file and utilize that information. I'm wondering if there is a more "Maven way", such as accessing a property for the dependency version.
EDIT: For clarification, we need the version number so we can get to the directory of the unpacked dependency to copy files.
I'm not sure what you mean with 'maven way' but I did something like this after looking at the same plugins you already mention:
<build>
<plugins>
<plugin>
<groupId>org.codehaus.gmaven</groupId>
<artifactId>gmaven-plugin</artifactId>
<version>1.5</version>
<executions>
<execution>
<phase>initialize</phase>
<goals>
<goal>execute</goal>
</goals>
<configuration>
<source>
project.properties.put('firstdependencyinthepom', project.dependencies[0]['version'])
project.properties.put('seconddependencyinthepom', project.dependencies[1]['version'])
</source>
</configuration>
</execution>
</executions>
</plugin>
and then I was able to refer to versions of these dependencies with ${firstdependencyinthepom} and ${seconddependencyinthepom} respectively.