I use the plugin version 3.0
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>hibernate3-maven-plugin</artifactId>
<version>3.0</version>
</plugin>
I don't know which dependencies are needed, which version of hibernate-tools I must add? Do I need to add hibernate-core too?
Thanks for helping.
The website says that the simplest plugin definition is this:
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>hibernate3-maven-plugin</artifactId>
<version>#pom.version#</version>
<configuration>
<hibernatetool>
<jpaconfiguration/>
</hibernatetool>
</configuration>
</plugin>
Where #pom.version# should be the latest plugin version. You won't need any other dependencies, that's what maven is for. Each plugin loads its own dependencies via the maven dependency mechanism.
Related
When I try to use maven-release-plugin in pom.xml, I am getting the following Warning:
Overriding managed version 2.5.3 for maven-release-plugin
I do not have parent pom. My pom.xml is to create standalone jar file. why is the above warning generated? where does maven get the version 2.5.3 ?
Here is my plugin info in pom.xml
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-release-plugin</artifactId>
<version>2.3.2</version>
<configuration>
<goals>pre-integration-test</goals>
<preparationGoals>package</preparationGoals>
<allowTimestampedSnapshots>true</allowTimestampedSnapshots>
<tagNameFormat>#{project.version}</tagNameFormat>
<remoteTagging>false</remoteTagging>
</configuration>
</plugin>
Thanks
Super POM
All models implicitly inherit from a super-POM:
...
<pluginManagement>
...
<plugin>
<artifactId>maven-release-plugin</artifactId>
<version>2.5.3</version>
</plugin>
I use the Versions Maven Plugin to check for updates of my dependencies. Therefore I added the following lines to my pom.xml:
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>versions-maven-plugin</artifactId>
<version>${versions-plugin.version}</version>
<configuration>
<rulesUri>classpath:///rules.xml</rulesUri>
</configuration>
<dependencies>
<dependency>
<groupId>versionrules</groupId>
<artifactId>versionrules</artifactId>
<version>1-SNAPSHOT</version>
</dependency>
</dependencies>
</plugin>
But this configuration is not used if I run the Versions Maven Plugin from the commandline in the same directory as the pom.xml. The only way to use my own configuration is to put this plugin configuration in a profil and execute this profil during the Maven run.
Is there a way to run the Versions plugin on the commandline and to configure it via the pom.xml? I am sure my questions does not only apply to the Versions plugin, but to any Maven plugin.
This can be done by using an execution id default-cli in your execution definition the configuration will be used during the execution on command line (using the current configuration) furthermore since Maven 3.3.1 you can use things like:
mvn version:set#second-cli
which means you can do a different configuration for command line in the pom file:
Just by simply separating them by different id
<build>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>versions-maven-plugin</artifactId>
<version>2.5.</version>
<executions>
<execution>
<id>default-cli</id>
<configuration>
...
</configuration>
</execution>
<execution>
<id>second-cli</id>
<configuration>
....
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
So this means you can have different configurations for running on command line by giving the id.
In our project, we have configured jetty inside build plugin in pom, i want to understand configuration settings in pom/ what and all we can configure in pom.
what is <build><plugin> section in pom, when to use.
difficult to understand from tutorials because lot of different examples which is making confuse.
Please can somebody explain for the above in detail?
Plugins defined in your buildsection plugins tag will be executed during the build of your project.
There are many plugins that do something with your build.
For example the maven-compiler-plugin which allows you to set the Java version for your project.
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.6.1</version>
<configuration>
<source>1.8</source>
<target>1.8</target>
</configuration>
</plugin>
</plugins>
</build>
a list of maven build plugins supported by maven itself
My pom contains a version number following a sequence similar to 2.0-SNAPSHOT, at the same time we build the project with a manifest file, that needs parts of that version number since other projects are dependent on the specific version, however to simplify parts of the development we use 2.0 as the implementation version, so we dont have to switch between 2.0-SNAPSHOT and 2.0 in our dependency setup i would like to know if its possible to exclude the -SNAPSHOT from the ${project.version} so we dont have to maintain a variable manually?
For such purposes the build-helper-maven-plugin is the right one like this:
<project>
...
<build>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>build-helper-maven-plugin</artifactId>
<version>1.8</version>
<executions>
<execution>
<id>parse-version</id>
<goals>
<goal>parse-version</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
...
</project>
It will provide the following properties:
parsedVersion.majorVersion
parsedVersion.minorVersion
parsedVersion.incrementalVersion
parsedVersion.qualifier
parsedVersion.buildNumber
Apart from that it sounds strange that you need the 2.0 as a released version where you don't have released the artifact yet. So you should think about using the maven-release-plugin to release artifacts which will change the version for your current project a like.
I have a maven project that uses the aspectj-compiler-plugin. I use intertype declarations so there are references to Aspect code in my Java code. Because of this, the maven-compiler-plugin fails to compile since it does not compile the aspect code.
My question is: how do I disable the maven-compiler-plugin from running because it is not doing anything useful?
There are several ways that I can get this project compiling, but they are sub-optimal:
Add exclusion filters to the maven-compiler-plugin. The plugin will still run, but it will not try to compile anything. Problem is that this breaks the ajdt project configurator in Eclipse
Move all java code to the aspectj folders. This doesn't feel right either.
You can disable the a plugin by set the phase of the plugin to none.
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<executions>
<execution>
<id>default-compile</id>
<phase>none</phase>
</execution>
</executions>
</plugin>
</plugins>
</build>
In Maven 3, the following will do this, for example disabling the clean plugin:
<build>
<plugins>
<plugin>
<artifactId>maven-clean-plugin</artifactId>
<version>2.4.1</version>
<executions>
<execution>
<id>default-clean</id>
<phase>none</phase>
</execution>
</executions>
</plugin>
</plugins>
</build>
The same technique can be used for any other plugin defined in the super-POM, the packaging type, or the parent POM. The key point is that you must copy the <id> shown by help:effective-pom, and change the <phase> to an invalid value (e.g. "none"). If you don't have the <id> (as e.g. in Jintian DENG's original answer – it has since been edited to add one), it will not work, as you have discovered.
Either configure the skipMain parameter:
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<skipMain>true</skipMain>
</configuration>
</plugin>
</plugins>
</build>
Or pass the maven.main.skip property:
mvn install -Dmaven.main.skip=true
The reason maven-compiler-plugin executes in the first place is because you trigger one of the default lifecycle bindings. For example if you're packaging jar using mvn package, it will trigger compile:compile at compile phase.
Maybe try not to use the default lifecycle, but use mvn aspectj:compile instead.
http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html has more information about maven default lifecycle bindings