I want to define property or want to use maven.plugin.classpath and maven.dependency.classpath in my build.xml.
How can i do it ?
Sample code is as below...
<property> </property> is not working and not able to read the values from my build.xml so please explain me how can i do it ?
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>exec-maven-plugin</artifactId>
<version>1.2</version>
<executions>
<execution>
<id>install</id>
<phase>install</phase>
<goals>
<goal>exec</goal>
</goals>
</execution>
</executions>
<configuration>
<property name="plugin_classpath" refid="maven.plugin.classpath" />
<property name="maven_dependency_classpath" refid="maven.dependency.classpath" />
<executable>antscript.bat</executable> <!-- ant -f build.xml build -->
</configuration>
</plugin>
Hi Sean Patrick Floyd,
Yes i tried using maven-antrun-plugin but i am not able to setup JDK 1.4.2 version in it. I am trying to specify all possible way to apply JDK version 1.4.2 but it's still taking tools.jar or JDK version, Which maven.bat file is using (jdk 1.5)
I was using following code in MAVEN-ANTRUN-PLUGIN as below code.
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-antrun-plugin</artifactId>
<version>1.6</version>
<executions>
<execution>
<id>install</id>
<phase>install</phase>
<goals>
<goal>run</goal>
</goals>
<configuration>
<source>${java-version}</source>
<target>${java-version}</target>
<compilerVersion>${java-version}</compilerVersion>
<executable>${java.1.4.2.home}/bin/javac</executable>
<target>
<property name="plugin_classpath" refid="maven.plugin.classpath" />
<property name="maven_dependency_classpath" refid="maven.dependency.classpath" />
<ant antfile="ant_build.xml" />
</target>
</configuration>
</execution>
</executions>
<dependencies>
<dependency>
<groupId>sun.jdk</groupId>
<artifactId>tools</artifactId>
<version>1.4.2</version>
<scope>system</scope>
<systemPath>${java.1.4.2.home}/lib/tools.jar</systemPath>
</dependency>
<dependency>
<groupId>com.sun</groupId>
<artifactId>rt</artifactId>
<version>${java-version}</version>
<scope>system</scope>
<systemPath>${java.1.4.2.home}/jre/lib/rt.jar</systemPath>
</dependency>
</dependencies>
</plugin>
That's why i choose exec GOAL where my SYSTEM JAVA_HOME is 1.4.2 and it's able to execute it if i have all dependencies which i needed.
Please help me out.
Thanks.
maven.plugin.classpath etc. are variables defined in the maven-antrun-plugin only. The exec plugin doesn't know about these values. Also, it wouldn't be possible to do it like that in the first place, as you are calling an external .bat file and hence starting a new process.
If I were you I'd use the antrun plugin. See the usage page for details.
Update: ok, now I see your problem. No, you can't use a different JDK, since antrun works within the same vm. So either you need to switch the JDK maven uses, or you do in fact need to use the exec-maven-plugin. In the latter case, you will have to use
dependency:build-classpath -DoutputFile=someFile.txt
and on the ant side, read the contents of someFile.txt as a property and create a classpath from it. Or you can use the %classpath variable placeholder in your command line args.
Yes correct answer which i found is to Use MAVEN version which supports JDK 1.4.2. So i have to use apache-maven-2.0.11 which supports JDK 1.4.2
Thanks all for your answers.
Related
I want to replace a file in an existing jar/zip file while doing a Maven build. What is the easiest way to achieve this?
My favorite for this sort of tasks is maven-antrun-plugin which brings you complete ant functionality.
You can use it like this:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-antrun-plugin</artifactId>
<version>1.6</version>
<executions>
<execution>
<id>repack</id>
<phase>compile</phase>
<goals>
<goal>run</goal>
</goals>
<configuration>
<target>
<!-- note that here we reference previously declared dependency -->
<unzip src="${org.apache:common-util:jar}" dest="${project.build.directory}/tmp"/>
<!-- now do what you need to any of unpacked files under target/tmp/ -->
<zip basedir="${project.build.directory}/tmp" destfile="${project.build.directory}/common-util-modified.jar"/>
<!-- now the modified jar is available -->
</target>
</configuration>
</execution>
</executions>
</plugin>
But remember - never modify any files in your local repository - in this example pointed to by ${org.apache:common-util:jar}. Doing so would affect your further builds of all your projects on the same computer (= against the same local repo).
Such builds are also irreproducible (or hard to reproduce) on other machines.
I don't think there is a dedicated plugin to do this but I would imagine you can use the exec plugin and information from Updating .class file in jar to accomplish this.
i have a maven project using the maven soapui plugin.
Unfortunately this one in my case need an external jar for jdbc for
some groovy scripts.
And according to their documentation, you have to add a repertory called "ext".
And after a dig in their code, this path is hardcoded in their plugin source.
You cant specify it.
So i have to add it directly to a subdirectory of MyProject :
Myproject/ext/postgresql.X.X.jar
I dont want to commit a jar in my project.
Is there a way to tell to maven to pickup a specific jar& add it to a specific directory ?
Thanks in advance for your answer.
You could use maven-dependency-plugin configured in your pom file to copy the artifact into that location during the generate-resources phase, something like this:
<plugin>
<artifactId>maven-dependency-plugin</artifactId>
<version>2.1</version>
<executions>
<execution>
<id>copy-postgresql-artifact</id>
<phase>generate-resources</phase>
<goals>
<goal>copy</goal>
</goals>
<configuration>
<outputDirectory>${basedir}/ext</outputDirectory>
<!-- if you need to rename the jar -->
<destFileName>postgresql.X.X.jar</destFileName>
<artifactItems>
<artifactItem>
<groupId>postgresql</groupId>
<artifactId>postgresql</artifactId>
<version>X.X</version>
</artifactItem>
</artifactItems>
</configuration>
</execution>
</executions>
</plugin>
I'm trying to add the svn.revision to project version as a build number and can't seem to do so. My jar has the correct name durin packaging, but its installed in the my local repository it is as if ${buildNumber} is/was undefined when the version was set.
I get foo-1.0.0-SNAPSHOT-${buildNumber} instead of foo-1.0.0-SNAPSHOT-304
Any idea what I'm doing wrong or is adding a revision to the project version a bad idea? Thanks for the help.
<project>
...
<version>1.0.0-${release.identifier}-${buildNumber}</version>
<properties>
<release.identifier>SNAPSHOT</release.identifier>
</properties>
...
<build>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>buildnumber-maven-plugin</artifactId>
<executions>
<execution>
<id>useLastCommittedRevision</id>
<goals>
<goal>create</goal>
</goals>
<configuration>
<useLastCommittedRevision>true</useLastCommittedRevision>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
...
</project>
The problem has two parts:
You're trying to set the buildNumber into the version before it is resolved so it will always be ${buildNumber} rather than the resolved value.
Instead of trying to dynamically change the version, you should set the buildNumber into the finalName element in the build. This will create the artifacts with the intended name in the local repository.
The install plugin will ignore the finalName and deploy it as 1.0.0-SNAPSHOT regardless, I don't know of a way to address that. The buildNumber is added to the Manifest if you configure the plugin as below.
So your configuration would be something like:
<version>1.0.0-${release.identifier}</version>
...
<build>
<finalName>${project.artifactId}-${project.version}-${buildNumber}</finalName>
...
</build>
I would avoid using build numbers on SNAPSHOT projects.
Maven provides the SNAPSHOT keyword to signify a volatile project in active development. So if you reference a project with a SNAPSHOT dependency version, Maven will automatically check for updates and keep your dependencies in sync.
If you then add a build number to the end of that version, you will have to manually update the dependencies, so you lose any benefit of having the SNAPSHOT suffix.
I personally avoid using build numbers where possible anyway. If I have to update a project, I just bump the version number, or use a suffix like beta-2 or RC2. If you need to track the revision in the SNAPSHOT, I'd recommend adding it to the Manifest so you can check where the build originated, but use the standard SNAPSHOT suffix to allow Maven to resolve the versions normally. The configuration below shows how to add the revision to the Manifest.
As far as your configuration is concerned, it looks OK to me assuming your SCM url is set up correctly. If you have no SCM configuration in your POM that may be the problem.
Can you run with -X and check for any output from the plugin indicating why it isn't setting the property?
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>buildnumber-maven-plugin</artifactId>
<version>0.9.4</version>
<executions>
<execution>
<id>useLastCommittedRevision</id>
<phase>validate</phase>
<goals>
<goal>create</goal>
</goals>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<version>2.1</version>
<configuration>
<archive>
<manifest>
<addDefaultImplementationEntries>true</addDefaultImplementationEntries>
</manifest>
<manifestEntries>
<Implementation-Build>${buildNumber}</Implementation-Build>
</manifestEntries>
</archive>
</configuration>
</plugin>
Add this after the buildnumber-maven-plugin:
<plugin>
<groupId>io.github.michaldo</groupId>
<artifactId>nashorn-maven-plugin</artifactId>
<version>0.0.1</version>
<executions>
<execution>
<phase>validate</phase>
<goals>
<goal>eval</goal>
</goals>
<configuration>
<script>
$project.artifact.version = "${buildNumber}";
</script>
</configuration>
</execution>
</executions>
</plugin>
And the buildNumber will be recognized by packaging and deploy.
I have a Maven POM file with a plugin that runs on the test phase. What command line arguments do I have to pass mvn in order to execute just that plugin rather than all of the plugins for that phase? I am also trying to execute a specific ant-run plugin, that looks like the following:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-antrun-plugin</artifactId>
<version>1.3</version>
<dependencies>
<dependency>
<groupId>com.googlecode.jslint4java</groupId>
<artifactId>jslint4java-ant</artifactId>
<version>1.3.3</version>
</dependency>
</dependencies>
<executions>
<execution>
<id>jslint</id>
<phase>test</phase>
<goals>
<goal>run</goal>
</goals>
<configuration>
<tasks>
<ant antfile="${basedir}/jslint.xml">
<property name="root" location="${basedir}" />
<target name="jslint" />
</ant>
</tasks>
</configuration>
</execution>
</executions>
</plugin>
Thanks.
Specify the fully-qualified goal in the form of:
mvn groupID:artifactID:version:goal
For example:
mvn sample.plugin:maven-hello-plugin:1.0-SNAPSHOT:sayhi
EDIT: I'm modifying my answer to cover the update of the initial question and a comment from the OP.
I won't cover all the details but, it the particular case of the antrun plugin, you could just run:
mvn antrun:run
But now that you've updated the question, I understand that things are a bit more complicated than what I thought initially and I don't think that this will actually work. I mean, invoking mvn antrun:run won't fail but it won't pick up the configuration of the execution bound to the test phase.
The only (ugly) solution I can think of would be to add another maven-antrun-plugin configuration in a specific profile, something like this:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-antrun-plugin</artifactId>
<version>1.3</version>
<dependencies>
<dependency>
<groupId>com.googlecode.jslint4java</groupId>
<artifactId>jslint4java-ant</artifactId>
<version>1.3.3</version>
</dependency>
</dependencies>
<configuration>
<tasks>
<ant antfile="${basedir}/jslint.xml">
<property name="root" location="${basedir}" />
<target name="jslint" />
</ant>
</tasks>
</configuration>
</plugin>
And to use this profile when calling antrun:run:
mvn antrun:run -Pmyprofile-for-antrun
I'm experimenting with Protocol Buffers in an existing, fairly vanilla Maven 2 project. Currently, I invoke a shell script every time I need to update my generated sources. This is obviously a hassle, as I would like the sources to be generated automatically before each build. Hopefully without resorting to shameful hackery.
So, my question is two-fold:
Long shot: is there a "Protocol Buffers plugin" for Maven 2 that can achieve the above in an automagic way? There's a branch on Google Code whose author appears to have taken a shot at implementing such a plugin. Unfortunately, it hasn't passed code review or been merged into protobuf trunk. The status of that plugin is thus unknown.
Probably more realistic: lacking an actual plugin, how else might I go about invoking protoc from my Maven 2 build? I suppose I may be able to wire up my existing shell script into an antrun invocation or something similar.
Personal experiences are most appreciated.
You'll find some information about the plugin available in the Protocol Buffers repository in the Protocol Buffers Compiler Maven Plug-In thread on the Protocol Buffers discussion group. My understanding is that it's usable but lacking tests. I'd give it a try.
Or you could just use the antrun plugin (snipet pasted from the thread mentioned above):
<build>
<plugins>
<plugin>
<artifactId>maven-antrun-plugin</artifactId>
<executions>
<execution>
<id>generate-sources</id>
<phase>generate-sources</phase>
<configuration>
<tasks>
<mkdir dir="target/generated-sources"/>
<exec executable="protoc">
<arg value="--java_out=target/generated-sources"/>
<arg value="src/main/protobuf/test.proto"/>
</exec>
</tasks>
<sourceRoot>target/generated-sources</sourceRoot>
</configuration>
<goals>
<goal>run</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
<dependencies>
<dependency>
<groupId>com.google.protobuf</groupId>
<artifactId>protobuf-java</artifactId>
<version>2.0.3</version>
</dependency>
</dependencies>
The accepted answer encouraged me to get the Google-provided plugin to work. I merged the branch mentioned in my question into a checkout of 2.2.0 source code, built and installed/deployed the plugin, and was able to use it in my project as follows:
<build>
<plugins>
<plugin>
<groupId>com.google.protobuf.tools</groupId>
<artifactId>maven-protoc-plugin</artifactId>
<version>0.0.1</version>
<executions>
<execution>
<id>generate-sources</id>
<goals>
<goal>compile</goal>
</goals>
<phase>generate-sources</phase>
<configuration>
<protoSourceRoot>${basedir}/src/main/protobuf/</protoSourceRoot>
<includes>
<param>**/*.proto</param>
</includes>
</configuration>
</execution>
</executions>
<configuration>
<protocExecutable>/usr/local/bin/protoc</protocExecutable>
</configuration>
</plugin>
</plugins>
</build>
Note that I changed the plugin's version to 0.0.1 (no -SNAPSHOT) in order to make it go into my non-snapshot thirdparty Nexus repository. YMMV. The takeaway is that this plugin will be usable once it's no longer necessary to jump through hoops in order to get it going.
The accepted solution does not scale for multiple proto files. I had to come up with my own:
<build>
<plugins>
<plugin>
<artifactId>maven-antrun-plugin</artifactId>
<executions>
<execution>
<id>compile-protoc</id>
<phase>generate-sources</phase>
<configuration>
<tasks>
<mkdir dir="${generated.sourceDirectory}" />
<path id="proto.path">
<fileset dir="src/main/proto">
<include name="**/*.proto" />
</fileset>
</path>
<pathconvert pathsep=" " property="proto.files" refid="proto.path" />
<exec executable="protoc" failonerror="true">
<arg value="--java_out=${generated.sourceDirectory}" />
<arg value="-I${project.basedir}/src/main/proto" />
<arg line="${proto.files}" />
</exec>
</tasks>
</configuration>
<goals>
<goal>run</goal>
</goals>
</execution>
</executions>
</plugin>
</build>
There's also great plugin by Igor Petruk named protobuf-maven-plugin. It's in central repo now and plays nicely with eclipse (m2e-1.1 is recommended).
I just updated the maven plugin to work with 2.2.0 -- the updated pom are attached to the code review bug.
Here are the instructions to build the plugin yourself:
svn co http://protobuf.googlecode.com/svn/branches/maven-plugin/tools/maven-plugin
cd maven-plugin
wget -O pom.xml 'http://protobuf.googlecode.com/issues/attachment?aid=8860476605163151855&name=pom.xml'
mvn install
You can then use the maven config above.
I just tried a less official but very recent (v 0.1.7) fork from https://github.com/dtrott/maven-protoc-plugin and it worked very well, courtesy of David Trott. I tested it with a couple of Maven modules one of which contained DTO-style messages and the other a service depending on them. I borrowed the plugin configuration MaxA posted on Oct 16 '09, I had protoc on my PATH and I added
<temporaryProtoFileDirectory>${basedir}/target/temp</temporaryProtoFileDirectory>
right after
<protocExecutable>protoc</protocExecutable>.
What is really nice is that all I had to do is to declare a normal dependency from the service module on the DTO module. The plugin was able to resolve proto files dependencies by finding the proto files packaged with the DTO module, extracting them to a temporary directory and using while generating code for the service. And it was smart enough not to package a second copy of the generated DTO classes with the service module.
There is a maven plugin for protobuf. https://www.xolstice.org/protobuf-maven-plugin/usage.html
The minimal config
<plugin>
<groupId>org.xolstice.maven.plugins</groupId>
<artifactId>protobuf-maven-plugin</artifactId>
<version>0.5.0</version>
<configuration>
<protocExecutable>/usr/local/bin/protoc</protocExecutable>
</configuration>
<executions>
<execution>
<goals>
<goal>compile</goal>
<goal>test-compile</goal>
</goals>
</execution>
</executions>
</plugin>
I think that using antrun to invoke non-Maven steps is the generally accepted solution.
You could also try the maven-exec-plugin.
I forked of the plugin from David Trott and have it compiling multiple languages which makes it a lot more useful. See the github project here and a tutorial on integrating it with a maven build here.