I have 2 artifacts that I'd like to copy from my local repository to a directory in filesystem.
I think dependency:copy does this job. But, it requires an argument artifactItems.
http://maven.apache.org/plugins/maven-dependency-plugin/examples/copying-artifacts.html
Can any one help me with using this goal in command line. Unfortunately, maven doesnt show the usage of this goal in command line.
Rather than trying to figure out how to provide an artifactItem by command line, I'd configure the command line execution for the dependency plugin. Do that by specifying default-cli as the execution ID. If you always want to copy the same dependencies, you could hardcode the GAV coords in the artifact item(s). Or, hardcode any values that remain constant between commands.
To copy different artifacts via command line, use properties as element values and specify the values on the command line. For example, if configuration for artifactItem included <artifactId>${copy.artifactId}</artifactId> then
mvn dependency:copy -Dcopy.artifactId=myArtifact
would copy myArtifact (example assumes other elements have hardcoded values).
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<version>2.4</version>
<executions>
<execution>
<id>default-cli</id>
<configuration>
<artifactItems>
<artifactItem>
<!-- hardcode values, or use properties, depending on what you want to do -->
<groupId>[ groupId ]</groupId>
<artifactId>[ artifactId ]</artifactId>
<version>[ version ]</version>
<type>[ packaging ]</type>
<outputDirectory>/the/filesystem/dir</outputDirectory>
</artifactItem>
</artifactItems>
<!-- other configurations here -->
</configuration>
</execution>
</executions>
</plugin>
Not sure if you want to do this from within a Maven project or without one. In case of the former, you can use this:
mvn dependency:copy -Dartifact='group.id:artifact.id:your.version'
In case you define the version of the artifact in your pom.xml using properties, you can also have it use that version like this:
mvn dependency:copy -Dartifact='group.id:artifact.id:${version.property}'
If you do not want to write artifactItems in your pom.xml, you could just use the command: "mvn dependency:copy-dependencies" instead of "mvn dependency:copy".
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 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.
I am using the preparationGoals configuration option of the Maven release plugin to transform additional files to reflect the version of the project being released. This works beautifully.
The problem is that when executing the commit, the plugin explicitly specifies that only the pom.xml files should be included thus leaving my other files uncommited:
[INFO] Executing: /bin/sh -c cd /Users/jw/dev/Test && git commit --verbose -F /var/folders/w0/hr1h_7h50f3_pwd_nrk9l808000195/T/maven-scm-114713951.commit pom.xml library/pom.xml sample/pom.xml
Is there any way for me to override this behavior and specify additional files or globs to include in the commit?
(I also need this behavior for the completionGoals as well which I have configured to do that same transformation)
I also need to commit some additional files (changed by Maven Replacer plugin). I did it in the following way:
First I configured Maven Release plugin to execute additional goals:
<plugin>
<artifactId>maven-release-plugin</artifactId>
<version>2.5.3</version>
<configuration>
<preparationGoals>-Prelease -DreplacerVersion="${releaseVersion}" clean replacer:replace scm:checkin verify</preparationGoals>
<completionGoals>-Prelease -DreplacerVersion="${developmentVersion}" clean replacer:replace scm:checkin verify</completionGoals>
</configuration>
</plugin>
release profile defines configuration of Maven SCM plugin
replacerVersion argument is used by Maven Replacer plugin to set correct version in some files
clean is a standard goal run by Maven Release plugin (default: clean verify)
replacer:replace goal is responsible for modifying files
scm:checkin does commit and push
verify is a standard goal run by Maven Release plugin (default: clean verify)
Next I configured Maven Replacer plugin:
<plugin>
<groupId>com.google.code.maven-replacer-plugin</groupId>
<artifactId>replacer</artifactId>
<version>1.5.3</version>
<configuration>
<includes>
<include>${basedir}/file1.txt</include>
<include>${basedir}/file2.txt</include>
</includes>
<replacements>
<replacement>
<token><![CDATA[<pattern>.*</pattern>]]></token>
<value><![CDATA[<pattern>${replacerVersion}</pattern>]]></value>
</replacement>
</replacements>
</configuration>
</plugin>
${replacerVersion} allows to use the same configuration for changing from a development to a release and next from the release to a next development version.
Finally I defined which version of Maven SCM plugin I want to use:
<plugin>
<artifactId>maven-scm-plugin</artifactId>
<version>1.9.5</version>
</plugin>
and configuration it in the release profile (I defined it in the profile to prevent accidental commits during non-release build):
<profile>
<id>release</id>
<build>
<pluginManagement>
<plugins>
<plugin>
<artifactId>maven-scm-plugin</artifactId>
<configuration>
<message>[maven-scm-plugin] set ${replacerVersion} version in files</message>
<includes>file1.txt, file2.txt</includes>
</configuration>
</plugin>
</plugins>
</pluginManagement>
</build>
</profile>
Thanks to that after executing a command:
mvn release:prepare -DdevelopmentVersion=1.2.1-SNAPSHOT -DreleaseVersion=1.2.0 -Dtag=1.2.0
I see 4 commits:
[maven-scm-plugin] set 1.2.0 version in files
[maven-release-plugin] prepare release 1.2.0
[maven-scm-plugin] set 1.2.1-SNAPSHOT version in files
[maven-release-plugin] prepare for next development iteration
Could you use the maven-scm-plugin? Add a plugin execution running the scm:checkin goal to commit the files you want. Bind it to a phase that will execute when preparationGoals are run (if you specified one or more phases as the value for that element), or include the scm:checkin goal in preparationGoals directly.
It appears the failure to allow specification of additional tag files is actually a bug in Maven. On line 130 in the org.apache.maven.shared.release.phase.AbstractScmCommitPhase class of the Maven Release Plugin, there are references to a "commitByProject" flag first introduced in Maven 2.0-beta-7.
A branch is used to determine the mechanism by which files are added to the Maven release:prepare commit. The SCM plugin is loaded with files in advance of the commit using the SCMFileSet class. One of the branch instantiations of that class may have been trying to add all files in the base directory, but it doesn't work that way in SCM.
This is a point where a fix could be implemented to take a list of files or to add a directory of files to commit.
Bottom line, after deep-diving into a debug execution of the Maven Release Plugin, it is invoking SCM Plugin to add only the POMs from the repos. Changing the poorly documented "commitByProject" flag has zero impact on the results in respect to which files are added into the SCM commit.
Another workaround is to configure another plugin (e.g. Maven AntRun Plugin) to manually run git add ., and then execute that as part of preparationGoals as well. This just happens to work and the modified files are part of the "[maven-release-plugin] prepare release ..." commit. However, I am not sure if this behavior is guaranteed, so this might rely on implementation details of the Maven Release Plugin.
Example configuration using the Maven AntRun Plugin to run git add:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-release-plugin</artifactId>
<version>3.0.0-M6</version>
<configuration>
<preparationGoals>
... other goals ...
antrun:run#git-add-changed
</preparationGoals>
</configuration>
</plugin>
<plugin>
<artifactId>maven-antrun-plugin</artifactId>
<version>3.1.0</version>
<executions>
<execution>
<id>git-add-changed</id>
<goals>
<goal>run</goal>
</goals>
<configuration>
<target>
<exec executable="git" dir="${project.basedir}" failonerror="true">
<arg value="add" />
<arg value="." />
</exec>
</target>
</configuration>
</execution>
</executions>
</plugin>
The main advantage of this compared to using the Maven SCM Plugin is that this does not require you to know in advance which files were modified and have to be committed. This can be useful when you replace a certain string in multiple files, e.g. #since NEXT in the Javadoc of all source files. With the scm:add goal of the Maven SCM Plugin the includes parameter seems to execute git add for all matching files separately, which will be slower and can cause issues when it matches by accident a file listed in .gitignore.