I just started using Maven and I read that plugins are additional components that can be used.
A typical structure of pom.xml file is
<project>
<groupId>org.koshik.javabrains</groupId>
<artifactId>JarName</artifactId> (A fldernamed JarName was created)
<version>1.0-SNAPSHOT</version>
<packaging>jar</packaging>
<name>JarName</name>
<url>http://maven.apache.org</url>
<properties>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
</properties>
<dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>3.8.1</version>
<scope>test</scope>
</dependency>
</dependencies>
</project>
Question: Where should I insert a plugin tag? such as the following:
<plugin>
<groupId>org.jibx</groupId>
<artifactId>jibx-maven-plugin</artifactId>
<version>1.2.4</version>
<executions>
<execution>
<goals>
<goal>bind</goal>
</goals>
</execution>
</executions>
</plugin>
Before the dependency or after the dependency tag? Does it matter?
<project>
<groupId>org.koshik.javabrains</groupId>
<artifactId>JarName</artifactId> (A fldernamed JarName was created)
<version>1.0-SNAPSHOT</version>
<packaging>jar</packaging>
<name>JarName</name>
<url>http://maven.apache.org</url>
<properties>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
</properties>
<build>
<plugins>
<plugin>
<groupId>org.jibx</groupId>
<artifactId>jibx-maven-plugin</artifactId>
<version>1.2.4</version>
<executions>
<execution>
<goals>
<goal>bind</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
<dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>3.8.1</version>
<scope>test</scope>
</dependency>
</dependencies>
</project>
You can also place plugins in the <build> section of <profile> if you use maven profiles. The order doesn't matter.
A late clarification on two important points
Where to place plugin
A plugin should indeed be added in most of the cases within the build/plugins section, however there is an important difference between placing it within plugins against placing it within pluginManagement/plugins.
This misunderstanding is often the cause of a non invoked plugin in Maven or an harder troubleshooting:
Plugins under build/plugins are directly part of the default Maven build, if they specify an execution or if they configure something for the default build (see below)
Plugins under build/pluginManagement/plugins are not necessarely part of the default Maven build, that is, is a management, it's an hint to maven: it you happen to use this plugin, then please use the version, the configuration, the executions I specify here, in this management.
But what happen to use means? Means: if the same plugin is also present in the build/plugins section, then apply this management (and only then it will be effective); or if the plugin is invoked by default by Maven, then also apply it.
But how is a plugin invoked by default? That's part of the main philosophy behind maven: convention over configuration. By convention, when you specify a certain packaging (default jar, but it can be war for example), you want certain plugins to be invoked. To build a jar, by default invoke the maven-jar-plugin; to build a war, by default invoke the maven-war-plugin and so on. So, if you specify a plugin configuration in the build/pluginManagement/plugin for a plugin which has a default binding to the Maven build, then it will be also be used.
Ordering
Concerning the ordering of sections within the pom.xml file, a further clarification is required: it's indeed irrelevant in most of the cases, however the order of plugin element wihtin the build/plugins section may be important. Since Maven 3.0.3 (MNG-2258), different plugin executions attached to the same Maven phase will be invoked in their order of declaration in the pom.xml file. That is, ordering is important in this case, since it may affect the behavior of the build.
Additionally, also order of dependency declarations may affect your build towards Dependency Mediation, that is, the first declared dependency wins in case of conflict against a transitive dependency. So, once again, ordering is important in certain cases.
Last but not least, although ordering is not important for other sections of the pom.xml file, good habit is to follow official Maven recommendations and, as a simplified version, follow this order of declaration:
<project>
<modelVersion/>
<parent/>
<groupId/>
<artifactId/>
<version/>
<packaging/>
<properties/>
<dependencyManagement/>
<dependencies/>
<build/>
<reporting/>
<profiles/>
</project>
The sortpom-maven-plugin can also be used to automatically apply this standard ordering, simply invoking the following on the concerned pom.xml file:
mvn com.github.ekryd.sortpom:sortpom-maven-plugin:2.5.0:sort \
-Dsort.keepBlankLines -Dsort.predefinedSortOrder=recommended_2008_06
For further reading:
Stack Overflow: Maven: what is pluginManagement?
Official Maven doc: Maven POM Reference, PluginManagement
Official Maven default bindings
Official Maven doc: Dependency Mediation
Official Maven doc: Maven Code Style And Code Conventions
<plugin>should be placed into <plugins> section which should be placed into <build> or <pluginManagement> section.
The order of <dependency> or <build> section doesn't matter.
The full reference about pom.xml is here: http://maven.apache.org/pom.html
If you want to use the plugin for build you can use the below structure.
<project>
<build>
<plugins>
</plugins>
</build>
</project>
You can insert your second snippet anywhere in the pom.xml file between two <plugins> </plugins> tags.
Sections order in POM doesn't matter. In general, there are build plugins and reporting plugins in Maven. Your case is to use build plugin so you have to put this <plugin> block into <project><build><plugins>... section.
Look at this for some basics about plugins.
As additional answer for Reporting Plugins (e.g. maven-checkstyle-plugin) there are 2 tags under which plugins can go in pom.xml, under build and reporting.
Using the reporting Tag VS build Tag
Configuring a reporting plugin in the or elements
in the pom does NOT have the same behavior!
mvn site
It uses only the parameters defined in the
element of each reporting Plugin specified in the element,
i.e. site always ignores the parameters defined in the
element of each plugin specified in .
mvn aplugin:areportgoal
It uses firstly the parameters defined in the element
of each reporting Plugin specified in the element; if a
parameter is not found, it will look up to a parameter defined in the
element of each plugin specified in .
Source: https://maven.apache.org/guides/mini/guide-configuring-plugins.html#Using_the_reporting_Tag_VS_build_Tag
Related
I'm using a BOM to import dependencies from another project to mine, and I need a way to reference a dependency's version that is already declared in said BOM. So far, I've attempted to list the dependency version as a property in the BOM, but this approach fails because properties don't get imported with BOMs.
I've seen where the Dependency Plugin's dependency:properties goal does almost exactly what I need, but instead of giving me a full path of the artifact I need the version as a property. Is there something out there that can give me the version of a resolved artifact as a property?
UPDATE - 'Why not use a parent pom?'
I commonly find myself working in application server environments, where the dependencies provided are specified with BOM artifacts (as it appears that this has become a somewhat common/standard way to distribute groups of inter-related artifacts, i.e. widlfly). As such, I want to treat the BOM as the single source of truth. The idea of doing something like re-delcaring a dependency version property that has already been defined in a BOM seems incorrect.
If I were to define properties in a parent pom that mirrored an application server's environment, I now have to worry about keeping parent pom properties and BOM properties in sync - why even have a BOM at all at that point?
The information is already available on the dependency tree, it's just a matter of exposing it...
Couldn't find any existing maven or plugin functionality for this, so I forked the old dependencypath-maven-plugin and altered it to use versions. Now I can drop in a plugin like this:
<build>
.
.
<plugins>
.
.
<plugin>
<groupId>io.reformanda.semper</groupId>
<artifactId>dependencyversion-maven-plugin</artifactId>
<version>1.0.0</version>
<executions>
<execution>
<id>set-all</id>
<goals>
<goal>set-version</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
And access properties like this:
groupId:artifactId:type[:classifier].version
I.E.
io.undertow:undertow-core:jar.version=1.3.15.Final
Check out the README for more info on how to use the plugin. It's available # Maven Central:
<dependency>
<groupId>io.reformanda.semper</groupId>
<artifactId>dependencyversion-maven-plugin</artifactId>
<version>1.0.0</version>
</dependency>
... plugins all the way down ...
Short answer - yes, you can.
In details, your root pom.xml:
<properties>
<slf4j.version>1.7.21</slf4j.version>
</properties>
...
<dependencyManagement>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-api</artifactId>
<version>${slf4j.version}</version>
</dependency>
...
</dependencyManagement>
In modules pom.xml:
<dependencies>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-api</artifactId>
</dependency>
...
</dependencies>
Also you can use ${slf4j.version} value to filter resources or in plugin configurations.
Update
In case you cannot use properties in the parent POM, you can either
retreive all dependencies and their versions with dependency:list plugin; or
use together dependency:list + antrun:run plugin; or
configure CI server scripts to do it for you (e.g. with this example); or
write a custom plugin to handle your versions logic.
This maven plugin is on Github (https://github.com/semper-reformanda/dependencyversion-maven-plugin) and it is a must for anyone dealing with Dependency versions, for instance when using Webjars dependencies - you can inject Webjar version numbers directly into your web resources.
I had been looking for such a functionality for a long time, I hope more people come across it and that it gets up on Maven central (I actually think it should come with Maven out of the box)
There is something I don't understand with maven and I didn't find any answer out there. So I ask it here, hoping to get an answer.
I added a jar as a maven dependency for a project as system scope.
When I run analyze-only goal on dependency plugin, it does find it. But whenever I want to use classes located in default package in this jar, it won't compile.
I did the same with a jar from same provider with same classes but this time located in one package other than default and it compiles.
Is there something obvious I missed or has someone already encountered the same problem ?
It is not worth posting the code as I just try to import one of the class of system dependency.
My POM (system dependency)
<?xml version="1.0" encoding="UTF-8"?>
<project>
<modelVersion>4.0.0</modelVersion>
<groupId>edu.algo</groupId>
<artifactId>algorithms</artifactId>
<version>1.0</version>
<properties>
<lib.path>C:/lib</lib.path>
</properties>
<dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.8.1</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>edu.princeton.cs</groupId>
<artifactId>stdlib</artifactId>
<version>1.0</version>
<scope>system</scope>
<systemPath>${lib.path}/stdlib/stdlib.jar</systemPath>
</dependency>
</dependencies>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<version>2.6</version>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>2.5.1</version>
<configuration>
<source>1.7</source>
<target>1.7</target>
</configuration>
</plugin>
</plugins>
</build>
</project>
Sorry to bother you guys and thanks for your help.
I found the answer to my question and it has nothing to do with maven. You just cannot import classes in default package from named package for java versions above 1.4, I was using 1.7 version for compilation.
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4989710
Have you supplied the JAR it's looking for? It sounds like it can't find the JAR against which to compile against.
Have you read this?
http://docs.codehaus.org/display/MAVENUSER/Dependency+Scopes
It states:
system: This dependency is required in some phase of your project's
lifecycle, but is system-specific. Use of this scope is discouraged:
This is considered an "advanced" kind of feature and should only be
used when you truly understand all the ramifications of its use, which
can be extremely hard if not actually impossible to quantify. This
scope by definition renders your build non-portable. It may be
necessarry in certain edge cases. The system scope includes the
element which points to the physical location of this
dependency on the local machine. It is thus used to refer to some
artifact expected to be present on the given local machine an not in a
repository; and whose path may vary machine-to-machine. The systemPath
element can refer to environment variables in its path: ${JAVA_HOME}
for instance.
So, unless you have a solid reason for using this, maybe it's better to deploy the artifact into the repository and reference it like any other artifact?
I have a war artefact and I need use some of their classes from a jar.
I can't move the classes to another project, then I deploy the classes and resources included in my webapp as an "attached" artifact using the following configuration:
<plugin>
<artifactId>maven-war-plugin</artifactId>
<version>2.1.1</version>
<configuration>
<attachClasses>true</attachClasses>
</configuration>
</plugin>
This will result in two artifacts being deployed: mywebapp-1.0-SNAPSHOT.war and mywebapp-1.0-SNAPSHOT-classes.jar.
To use those classes I Referencing the artifact as follows:
<dependency>
<groupId>mygroup</groupId>
<artifactId>mywebapp</artifactId>
<version>${project.version}</version>
<classifier>classes</classifier>
</dependency>
When I compiled from Jenkins everything works correctly, but when I run the tests locally from Eclipse can not find the reference classes. (java.lang.NoClassDefFoundError)
I think it might be a bug in the maven eclipse plugin, someone has any idea that can be happening?
Workaround is described on http://wiki.eclipse.org/M2E-WTP_FAQ:
A workaround exists though, we need to change the dependency whether the project is built in Eclipse or not. In your dependent project, you can configure the following :
<dependencies>
...
<dependency>
<groupId>com.company</groupId>
<artifactId>mywebapp</artifactId>
<version>1.0.0-SNAPSHOT</version>
<classifier>${webClassifier}</classifier>
</dependency>
...
</dependencies>
...
<properties>
...
<webClassifier>classes</webClassifier>
</properties>
...
<profiles>
<profile>
<id>m2e</id>
<activation>
<property>
<name>m2e.version</name>
</property>
</activation>
<properties>
<webClassifier></webClassifier>
</properties>
</profile>
</profiles>
The m2e profile is automatically activated when the project is built with m2e, ignored in other circumstances. In that case only, the dependent project will use an empty classifier to reference the web project, which will be added to the classpath as expected.
My simple answer is the following link to the bug tracking system of Eclipse:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=365419
See the answers inside.
Yes it's a problem with Eclipse itself..
The solution within Eclipse just add the project manually within your workspace to the appropriate project where you need the classes out of your war project.
I'm developing a new mojo. It has only one goal so it seems logical not to force a user to add an executions section (if they don't want to change a default phase).
This should be possible because when I add a very simple description of a surefire plugin, maven understands that its single goal test should be run, i.e.:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.4.3</version>
</plugin>
and this is enough to run the plugin.
How can I achieve similarly small configuration for my plugin?
Here is what I have now (and it doesn't work without executions section):
/**
*
* #goal test
* #phase test
*/
public class MyMojoPlugin extends AbstractMojo {
... (implementation details)
}
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>org.somegroup</groupId>
<artifactId>mymojo-maven-plugin</artifactId>
<packaging>maven-plugin</packaging>
<version>1.0-SNAPSHOT</version>
<dependencies>
<dependency>
<groupId>org.apache.maven</groupId>
<artifactId>maven-plugin-api</artifactId>
<version>2.0</version>
</dependency>
.... (other dependencies)
</dependencies>
<build>
<plugins>
... (some plugins)
</plugins>
</build>
</project>
The "default" lifecycle bindings are defined within Maven. This is described in the Build Lifecycle document, which document also indicates that the "executions" section is required for plugins.
I suppose that you could edit components.xml and recompile Maven for your particular site.
In my opinion a better alternative, for in-house development at least, is to use a shared Parent POM that contains site-specific configuration.
Edit: I was looking for a reference to Parent POMs and saw this. I'm not sure if that's a Maven3-only feature, but it's probably worth investigating.
I often encounter distributions of Java applications or libraries which
use Maven as their build tool.
Some of them, sadly, don't provide standalone (or redistributable) jars.
Is it possible to build Maven-based applications in such a way, that
the build result contains all dependencies and can be redistributed to work out-of-the box?
I tried to build Jackrabbit's OCM module.
For some very "intelligent" reasons there is no downloadable standalone
version.
So I built Jackrabbit with Maven (the source package of Jackrabbit includes
OCM), and got the same jar as found in the apache repository.
The jar doesn't contain necessary dependencies and is useless to me.
As Dominic said, using the assembly plugin will do the trick. You would usually configure it inside your own project's POM to gather and package all required dependencies:
...
<plugin>
<artifactId>maven-assembly-plugin</artifactId>
<configuration>
<descriptorRefs>
<descriptorRef>jar-with-dependencies</descriptorRef>
</descriptorRefs>
</configuration>
</plugin>
...
jar-with-dependencies is predefined by the assembly plugin and will include all dependencies in the final package (see the documentation here).
If you don't want to use Maven for your own project, you will need to modify the libraries' POMs and repackage them yourself (download the sources, add the above snippet to pom.xml and run mvn package). Beware of duplicate or incompatible transitive dependencies if you use multiple libraries. exclusions might help in that case (see documentation here).
Use the Maven Shade plugin
...but be careful of the gotchas (similar to the one described further down my answer), which has got a workaround explained here.
Also, be ultra careful with the Shade plugin config. I accidentally used double <configuration> tags once, and the transformers didn't apply at all, and the plugin also took the liberty of not warning me.
Don't use the Maven Assembly plugin
assembly:single will unpack your dependency JARs as-is, and this could not be what you want. E.g. stuff like META-INF/spring.schemas will be overridden with the last Spring dependency JAR that's evaluated, and as such your XSDs won't be found (apart from those in the last JAR, of course). Which is why systems like Alfresco made their AMP plugin which bundles dependencies inside lib/ inside the AMP you're building. The latter raises dependency management issues, though.
You may have some luck with the appassembler plugin. Failing that, take a look at the assembly plugin. That's more flexible, but lower level. If you're using the assembly plugin, you may find the chapter on it in maven: the definitive guide to be useful.
As a couple of the posters said, the assembly plugin is a good way of creating a complete jar file, with all project dependencies. However, you don't actually have to modify the pom.xml file. Simply run:
mvn assembly:single -DdescriptorId=jar-with-dependencies
... in order to create a jar file. If you want to do anything more advanced, you should probably modify pom.xml, and create a custom assembly descriptor.
Change the pom.xml file and use the <Embed-Dependency> directive. A similar example can be found here so you can adapt it to your scenario.
<Embed-Dependency>*;scope=!test;inline=true</Embed-Dependency>
I think this should do the trick.
Here is the example at the above URL that seems to give timeout.
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>br.gov.lexml</groupId>
<artifactId>toolkit</artifactId>
<packaging>bundle</packaging>
<version>3.0</version>
<parent>
<artifactId>lexml</artifactId>
<groupId>br.gov.lexml</groupId>
<version>1.0</version>
</parent>
<build>
<finalName>Lexml_Toolkit-2.0</finalName>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<source>1.5</source>
<target>1.5</target>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.felix</groupId>
<artifactId>maven-bundle-plugin</artifactId>
<extensions>true</extensions>
<configuration>
<instructions>
<!--_include>src/toolkit/resources/META-INF/MANIFEST.MF</_include-->
<Export-Package>*;-split-package:=merge-last</Export-Package>
<Bundle-Activator>br.gov.lexml.borda.Toolkit</Bundle-Activator>
<Bundle-Name>Toolkit</Bundle-Name>
<Private-Package />
<Embed-Dependency>*;scope=!test;inline=true</Embed-Dependency>
<Bundle-ClassPath>.,{maven-dependencies}</Bundle-ClassPath>
</instructions>
</configuration>
</plugin>
</plugins>
</build>
<dependencies>
<dependency>
<groupId>org.apache.xmlbeans</groupId>
<artifactId>xmlbeans</artifactId>
<version>2.4.0</version>
</dependency>
<dependency>
<groupId>org.apache.xmlbeans</groupId>
<artifactId>xmlbeans-xmlpublic</artifactId>
<version>2.4.0</version>
</dependency>
<dependency>
<groupId>log4j</groupId>
<artifactId>log4j</artifactId>
<version>1.2.15</version>
</dependency>
<dependency>
<groupId>br.gov.lexmlbeans</groupId>
<artifactId>lexmlbeans</artifactId>
<version>3.0</version>
</dependency>
</dependencies>
</project>
I believe the Maven Shade Plugin will satisfy your needs. I use it when I am building command line interface tools to create an Uber JAR including my classes and along with the classes from all my dependencies.
Its very easy to use and I think this example is self-explanatory.