https://github.com/xwiki/xwiki-commons
Revision 6869ceb49d94e7f0a915991d0a54b3a467108aaf authored by tmortagne on 27 February 2015, 15:37:11 UTC, committed by tmortagne on 27 February 2015, 15:37:11 UTC
1 parent d9ed262
Tip revision: 6869ceb49d94e7f0a915991d0a54b3a467108aaf authored by tmortagne on 27 February 2015, 15:37:11 UTC
XCOMMONS-736: Add support for extensions categories
XCOMMONS-736: Add support for extensions categories
Tip revision: 6869ceb
pom.xml
<?xml version="1.0" encoding="UTF-8"?>
<!--
* See the NOTICE file distributed with this work for additional
* information regarding copyright ownership.
*
* This is free software; you can redistribute it and/or modify it
* under the terms of the GNU Lesser General Public License as
* published by the Free Software Foundation; either version 2.1 of
* the License, or (at your option) any later version.
*
* This software is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
* Lesser General Public License for more details.
*
* You should have received a copy of the GNU Lesser General Public
* License along with this software; if not, write to the Free
* Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
* 02110-1301 USA, or see the FSF site: http://www.fsf.org.
-->
<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.xwiki.commons</groupId>
<artifactId>xwiki-commons</artifactId>
<name>XWiki Commons - Parent POM</name>
<packaging>pom</packaging>
<version>7.0-SNAPSHOT</version>
<description>A collaborative development platform runtime based on the wiki paradigm</description>
<!-- This special URL automatically finds the correct documentation page or javadoc for the module based on the
passed maven coordinates (groupid:artifactid:version). Starting with 6.2-milestone-1, the version has been
added to better support javadoc links.
It allows to have a single URL definition in this top level POM and still get valid website URLs for all
modules.
Note that we're ending the URL with ":::" for the following reasons:
- Since we don't overwrite the <url> element in children POM, Maven automatically appends the relative path
to the children modules. For example:
"/xwiki-commons-pom/xwiki-commons-core/xwiki-commons-component/xwiki-commons-component-api"
and the javadoc produce external link using a path like for example:
"/xwiki-commons-pom/.../apidocs/org/xwiki/model/reference/DocumentReference.html?is-external=true"
- Ideally we would use instead a generic URL like:
"http://extensions.xwiki.org?id=${project.groupId}:${project.artifactId}&path="
However this makes the site plugin fails, see http://jira.codehaus.org/browse/MNG-5242
-->
<url>http://extensions.xwiki.org?id=${project.groupId}:${project.artifactId}:${project.version}:::</url>
<inceptionYear>2004</inceptionYear>
<properties>
<!-- Define it here because we can't use ${project.version} for plugins and it's useful for
commons children anyway -->
<commons.version>7.0-SNAPSHOT</commons.version>
<!-- The previous stable version of this project for CLIRR, used to catch API breakages. -->
<xwiki.clirr.previous.version>6.4</xwiki.clirr.previous.version>
<!-- REST -->
<restlet.version>2.0.14</restlet.version>
<!-- Selenium -->
<selenium.version>2.44.0</selenium.version>
<!-- SLF4J -->
<slf4j.version>1.7.10</slf4j.version>
<!-- Hamcrest -->
<hamcrest.version>1.3</hamcrest.version>
<!-- JUnit -->
<junit.version>4.12</junit.version>
<!-- Mock libraries -->
<jmock.version>2.6.0</jmock.version>
<mockito.version>1.10.19</mockito.version>
<!-- AspectJ -->
<aspectj.version>1.8.5</aspectj.version>
<!-- Clover -->
<clover.version>3.1.12</clover.version>
<!-- IzPack -->
<izpack.version>5.0.0-rc1</izpack.version>
<!-- By default Checkstyle, CLIRR, Enforcer and License plugins are on -->
<xwiki.checkstyle.skip>false</xwiki.checkstyle.skip>
<xwiki.clirr.skip>false</xwiki.clirr.skip>
<xwiki.enforcer.skip>false</xwiki.enforcer.skip>
<xwiki.license.skip>false</xwiki.license.skip>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
<!-- Functional UI tests should not check if an XWiki instance is already running before starting XWiki since
performing this check would delay the build and there should be no running instance when the build executes -->
<xwiki.test.verifyRunningXWikiAtStart>false</xwiki.test.verifyRunningXWikiAtStart>
<!-- Sonar/Jacoco integration. Note that these properties need to be defined outside the "coverage" profile
because we want to be to able to execute mvn sonar:sonar without passing a profile -->
<!-- Tells Sonar to use jacoco for coverage results -->
<sonar.java.coveragePlugin>jacoco</sonar.java.coveragePlugin>
<!-- The system property xwiki.jacoco.itDestFile needs to be passed on the command line.
Example:
mvn clean install -Pcoverage -Dxwiki.jacoco.itDestFile=`pwd`/target/jacoco-it.exec
Note that unfortunately using the following does not work because of
http://jira.codehaus.org/browse/SONAR-3427:
<xwiki.jacoco.itDestFile>
${session.executionRootDirectory}/target/xwiki-jacoco-it.exec
</xwiki.jacoco.itDestFile>
-->
<!-- Tells Sonar where the Jacoco coverage result file is located for IT tests so that Sonar can display coverage
for ITs -->
<sonar.jacoco.itReportPath>${xwiki.jacoco.itDestFile}</sonar.jacoco.itReportPath>
</properties>
<prerequisites>
<maven>3.0</maven>
</prerequisites>
<licenses>
<license>
<name>LGPL 2.1</name>
<url>http://www.gnu.org/licenses/old-licenses/lgpl-2.1.html</url>
<distribution>repo</distribution>
</license>
</licenses>
<issueManagement>
<system>jira</system>
<url>http://jira.xwiki.org/jira/browse/XCOMMONS</url>
</issueManagement>
<developers>
<!-- Note that this information is read by XWiki's Extension Manager and passed to the XWiki Repository Application
to mention who developed the various published XWiki extensions. We use a fake Developer who represents the
whole team because it's simpler to manage only one developer at this level and instead use the wiki at
http://dev.xwiki.org/xwiki/bin/view/Community/HallOfFame to provide an up to date view of all XWiki devs. -->
<developer>
<id>devs</id>
<name>XWiki Development Team</name>
</developer>
</developers>
<organization>
<name>XWiki</name>
<url>http://xwiki.org/</url>
</organization>
<scm>
<connection>scm:git:git://github.com/xwiki/xwiki-commons.git</connection>
<developerConnection>scm:git:git@github.com:xwiki/xwiki-commons.git</developerConnection>
<url>https://github.com/xwiki/xwiki-commons/tree/master/</url>
<tag>xwiki-commons-4.4-milestone-1</tag>
</scm>
<mailingLists>
<mailingList>
<name>XWiki Users List</name>
<post>users@xwiki.org</post>
<subscribe>http://lists.xwiki.org/mailman/listinfo/users</subscribe>
<unsubscribe>http://lists.xwiki.org/mailman/listinfo/users</unsubscribe>
<archive>http://lists.xwiki.org/pipermail/users/</archive>
<otherArchives>
<otherArchive>http://xwiki.markmail.org/</otherArchive>
<otherArchive>http://www.nabble.com/XWiki-f2563.html</otherArchive>
<otherArchive>http://gmane.org/find.php?list=xwiki</otherArchive>
</otherArchives>
</mailingList>
<mailingList>
<name>XWiki Developers List</name>
<post>devs@xwiki.org</post>
<subscribe>http://lists.xwiki.org/mailman/listinfo/devs</subscribe>
<unsubscribe>http://lists.xwiki.org/mailman/listinfo/devs</unsubscribe>
<archive>http://lists.xwiki.org/pipermail/devs/</archive>
<otherArchives>
<otherArchive>http://xwiki.markmail.org/</otherArchive>
<otherArchive>http://www.nabble.com/XWiki-f2563.html</otherArchive>
<otherArchive>http://gmane.org/find.php?list=xwiki</otherArchive>
</otherArchives>
</mailingList>
</mailingLists>
<dependencyManagement>
<!-- Standard dependencies used in several XWiki build modules. Ensures all modules
use the same version for these dependencies -->
<dependencies>
<!-- Apache Commons -->
<dependency>
<groupId>org.apache.commons</groupId>
<artifactId>commons-lang3</artifactId>
<version>3.3.2</version>
</dependency>
<!-- We don't use Commons Lang 2.x ourselves (we use Commons Lang 3.x) but some of our transitive dependencies
require Commons Lang. The issue is that Maven uses a "closest-to-root" strategy to resolve dependency
versions and since the transitive dependencies that require Commons Lang don't use version ranges we need
to help them... (see http://guntherpopp.blogspot.fr/2011/02/understanding-maven-dependency.html). Since
the Commons Lang project takes a lot of care of preserving backward compatibility we force to use the
latest version which is the version that has the least chance of causing problems! -->
<dependency>
<groupId>commons-lang</groupId>
<artifactId>commons-lang</artifactId>
<version>2.6</version>
</dependency>
<dependency>
<groupId>org.apache.commons</groupId>
<artifactId>commons-collections4</artifactId>
<version>4.0</version>
</dependency>
<dependency>
<groupId>commons-collections</groupId>
<artifactId>commons-collections</artifactId>
<version>3.2.1</version>
</dependency>
<dependency>
<groupId>commons-io</groupId>
<artifactId>commons-io</artifactId>
<version>2.4</version>
</dependency>
<dependency>
<groupId>commons-net</groupId>
<artifactId>commons-net</artifactId>
<version>3.3</version>
</dependency>
<!-- Apache HttpComponents -->
<dependency>
<groupId>org.apache.httpcomponents</groupId>
<artifactId>httpclient</artifactId>
<version>4.4</version>
<!-- We want to choose the SLF4J binding only when XWiki is packaged. -->
<exclusions>
<exclusion>
<groupId>commons-logging</groupId>
<artifactId>commons-logging</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>org.apache.httpcomponents</groupId>
<artifactId>httpmime</artifactId>
<version>4.4</version>
</dependency>
<dependency>
<groupId>org.apache.httpcomponents</groupId>
<artifactId>httpcore</artifactId>
<version>4.4</version>
</dependency>
<dependency>
<groupId>org.apache.httpcomponents</groupId>
<artifactId>httpcore-nio</artifactId>
<version>4.4</version>
</dependency>
<!-- Old httpclient -->
<dependency>
<groupId>commons-httpclient</groupId>
<artifactId>commons-httpclient</artifactId>
<version>3.1</version>
<!-- We want to choose the SLF4J binding only when XWiki is packaged. -->
<exclusions>
<exclusion>
<groupId>commons-logging</groupId>
<artifactId>commons-logging</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>org.apache.commons</groupId>
<artifactId>commons-dbcp2</artifactId>
<version>2.1</version>
<!-- We want to choose the SLF4J binding only when XWiki is packaged. -->
<exclusions>
<exclusion>
<groupId>commons-logging</groupId>
<artifactId>commons-logging</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>commons-fileupload</groupId>
<artifactId>commons-fileupload</artifactId>
<version>1.3.1</version>
</dependency>
<dependency>
<groupId>commons-codec</groupId>
<artifactId>commons-codec</artifactId>
<version>1.10</version>
</dependency>
<dependency>
<groupId>commons-beanutils</groupId>
<artifactId>commons-beanutils</artifactId>
<version>1.9.2</version>
<!-- We want to choose the SLF4J binding only when XWiki is packaged. -->
<exclusions>
<exclusion>
<groupId>commons-logging</groupId>
<artifactId>commons-logging</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>commons-configuration</groupId>
<artifactId>commons-configuration</artifactId>
<version>1.10</version>
<!-- We want to choose the SLF4J binding only when XWiki is packaged. -->
<exclusions>
<exclusion>
<groupId>commons-logging</groupId>
<artifactId>commons-logging</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>org.apache.commons</groupId>
<artifactId>commons-compress</artifactId>
<version>1.9</version>
</dependency>
<!-- XML processing -->
<dependency>
<groupId>com.thoughtworks.xstream</groupId>
<artifactId>xstream</artifactId>
<version>1.4.7</version>
</dependency>
<dependency>
<groupId>dom4j</groupId>
<artifactId>dom4j</artifactId>
<version>1.6.1</version>
</dependency>
<dependency>
<groupId>org.jdom</groupId>
<artifactId>jdom</artifactId>
<version>1.1.3</version>
</dependency>
<dependency>
<groupId>org.jdom</groupId>
<artifactId>jdom2</artifactId>
<version>2.0.5</version>
</dependency>
<dependency>
<groupId>net.java.dev.stax-utils</groupId>
<artifactId>stax-utils</artifactId>
<version>20070216</version>
<exclusions>
<!-- Not needed since Java 1.6 -->
<exclusion>
<groupId>com.bea.xml</groupId>
<artifactId>jsr173-ri</artifactId>
</exclusion>
</exclusions>
</dependency>
<!-- What is included in the JRE is too old and Oracle does not seems to plan to upgrade it anytime soon -->
<dependency>
<groupId>xerces</groupId>
<artifactId>xercesImpl</artifactId>
<version>2.11.0</version>
</dependency>
<!-- xerces require this version of xml-apis -->
<dependency>
<groupId>xml-apis</groupId>
<artifactId>xml-apis</artifactId>
<version>1.4.01</version>
</dependency>
<!-- Jackson -->
<dependency>
<groupId>org.codehaus.jackson</groupId>
<artifactId>jackson-core-asl</artifactId>
<version>1.9.13</version>
</dependency>
<dependency>
<groupId>org.codehaus.jackson</groupId>
<artifactId>jackson-mapper-asl</artifactId>
<version>1.9.13</version>
</dependency>
<!-- Used in both commons and platform -->
<dependency>
<groupId>net.sf.json-lib</groupId>
<artifactId>json-lib</artifactId>
<version>2.4</version>
<classifier>jdk15</classifier>
<!-- We want to choose the SLF4J binding only when XWiki is packaged. -->
<exclusions>
<exclusion>
<groupId>commons-logging</groupId>
<artifactId>commons-logging</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>org.bouncycastle</groupId>
<artifactId>bcprov-jdk15on</artifactId>
<version>1.49</version>
</dependency>
<dependency>
<groupId>org.bouncycastle</groupId>
<artifactId>bcpkix-jdk15on</artifactId>
<version>1.49</version>
</dependency>
<dependency>
<groupId>org.bouncycastle</groupId>
<artifactId>bcmail-jdk15on</artifactId>
<version>1.49</version>
</dependency>
<!-- Various project are using it to scan the classpath -->
<dependency>
<groupId>org.reflections</groupId>
<artifactId>reflections</artifactId>
<version>0.9.9</version>
</dependency>
<!-- netcdf 4.2-min wrongly embbeds jcip classes -->
<dependency>
<groupId>edu.ucar</groupId>
<artifactId>netcdf</artifactId>
<version>4.2.20</version>
</dependency>
<!-- Used by reflections and other projects in commons, platform and rendering -->
<dependency>
<groupId>com.google.guava</groupId>
<artifactId>guava</artifactId>
<version>18.0</version>
</dependency>
<!-- Groovy engine. Used in both commons and platform -->
<dependency>
<groupId>org.codehaus.groovy</groupId>
<artifactId>groovy-all</artifactId>
<version>2.4.1</version>
</dependency>
<!-- Everybody logs -->
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-api</artifactId>
<version>${slf4j.version}</version>
</dependency>
<!-- SLF4J implementation we use -->
<dependency>
<groupId>ch.qos.logback</groupId>
<artifactId>logback-classic</artifactId>
<version>1.1.2</version>
</dependency>
<!-- External libraries using Commons Logging will delegate to SLF4J -->
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>jcl-over-slf4j</artifactId>
<version>${slf4j.version}</version>
</dependency>
<!-- External libraries using Log4J will delegate to SLF4J -->
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>log4j-over-slf4j</artifactId>
<version>${slf4j.version}</version>
</dependency>
<!-- Make sure everyone use the same version of JBoss Logging -->
<dependency>
<groupId>org.jboss.logging</groupId>
<artifactId>jboss-logging</artifactId>
<version>3.1.3.GA</version>
</dependency>
<!-- Triggerd by several Maven related projects (Doxia, Maven, Aether) as transitive dependency -->
<dependency>
<groupId>org.codehaus.plexus</groupId>
<artifactId>plexus-utils</artifactId>
<version>3.0.17</version>
</dependency>
<!-- Everybody tests -->
<dependency>
<groupId>org.hamcrest</groupId>
<artifactId>hamcrest-core</artifactId>
<version>${hamcrest.version}</version>
</dependency>
<dependency>
<groupId>org.hamcrest</groupId>
<artifactId>hamcrest-library</artifactId>
<version>${hamcrest.version}</version>
</dependency>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>${junit.version}</version>
</dependency>
<dependency>
<groupId>org.jmock</groupId>
<artifactId>jmock</artifactId>
<version>${jmock.version}</version>
</dependency>
<dependency>
<groupId>org.jmock</groupId>
<artifactId>jmock-junit4</artifactId>
<version>${jmock.version}</version>
</dependency>
<dependency>
<groupId>org.jmock</groupId>
<artifactId>jmock-legacy</artifactId>
<version>${jmock.version}</version>
</dependency>
<dependency>
<groupId>org.mockito</groupId>
<artifactId>mockito-core</artifactId>
<version>${mockito.version}</version>
</dependency>
<dependency>
<groupId>org.seleniumhq.selenium</groupId>
<artifactId>selenium-java</artifactId>
<version>${selenium.version}</version>
<exclusions>
<!-- We want to choose the SLF4J binding only when XWiki is packaged. -->
<exclusion>
<groupId>commons-logging</groupId>
<artifactId>commons-logging</artifactId>
</exclusion>
<!-- It has a dependency on testng which we need to exclude to prevent
Maven Surefire plugin to think we're executing TestNG tests. -->
<exclusion>
<groupId>org.testng</groupId>
<artifactId>testng</artifactId>
</exclusion>
</exclusions>
</dependency>
<!-- Most plugins depend on the servlet API -->
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>servlet-api</artifactId>
<!-- Note: The 2.4 version is not technically correct as 2.4 corresponds to a specification
# and is not an implementation version. The central repo would need to be fixed... -->
<version>2.4</version>
<!-- It should always be provided, otherwise containers will complain about it. -->
<scope>provided</scope>
</dependency>
<!-- Needed for Legacy modules. The version needs to be in sync with the one used by the AspectJ plugin -->
<dependency>
<groupId>org.aspectj</groupId>
<artifactId>aspectjrt</artifactId>
<version>${aspectj.version}</version>
</dependency>
<!-- CSS parsing -->
<dependency>
<groupId>net.sourceforge.cssparser</groupId>
<artifactId>cssparser</artifactId>
<version>0.9.14</version>
</dependency>
<!-- Bean validation -->
<dependency>
<groupId>javax.validation</groupId>
<artifactId>validation-api</artifactId>
<version>1.0.0.GA</version>
</dependency>
<!-- Mail -->
<dependency>
<groupId>javax.mail</groupId>
<artifactId>mail</artifactId>
<version>1.4.5</version>
<exclusions>
<!-- We exclude it since it draws version 1.1 and other dependencies we have draw version 1.1.1 -->
<exclusion>
<groupId>javax.activation</groupId>
<artifactId>activation</artifactId>
</exclusion>
</exclusions>
</dependency>
<!-- Diff tools used in commons for diff and blame -->
<dependency>
<groupId>com.googlecode.java-diff-utils</groupId>
<artifactId>diffutils</artifactId>
<version>1.3.0</version>
</dependency>
<!-- Apache Velocity -->
<dependency>
<groupId>org.apache.velocity</groupId>
<artifactId>velocity</artifactId>
<version>1.7</version>
</dependency>
<!-- Apache Velocity Tools -->
<dependency>
<groupId>org.apache.velocity</groupId>
<artifactId>velocity-tools</artifactId>
<version>2.0</version>
<exclusions>
<!-- We want to choose the SLF4J binding only when XWiki is packaged. -->
<!-- Note: Because of this exclusion, we need to manually add servlet-api
to the dependencies list each time we depend on velocity-tools. -->
<exclusion>
<groupId>commons-logging</groupId>
<artifactId>commons-logging</artifactId>
</exclusion>
</exclusions>
</dependency>
</dependencies>
</dependencyManagement>
<build>
<defaultGoal>install</defaultGoal>
<plugins>
<!-- Ensure that we lock down all plugin versions -->
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-enforcer-plugin</artifactId>
<!-- Lock down plugin version for build reproducibility -->
<version>1.3.1</version>
<configuration>
<skip>${xwiki.enforcer.skip}</skip>
</configuration>
<executions>
<!-- Check that all Maven plugins have versions defined -->
<execution>
<id>enforce-plugins</id>
<goals>
<goal>enforce</goal>
</goals>
<configuration>
<rules>
<requirePluginVersions>
<message>Best Practice is to always define plugin versions!</message>
<banLatest>false</banLatest>
<banRelease>false</banRelease>
<banSnapshots>false</banSnapshots>
</requirePluginVersions>
</rules>
</configuration>
</execution>
<!-- Check that we're using SLF4J only -->
<execution>
<id>enforce-jcl-log4j-isolation</id>
<goals>
<goal>enforce</goal>
</goals>
<configuration>
<rules>
<bannedDependencies>
<searchTransitive>true</searchTransitive>
<message>
XWiki uses SLF4J for logging. Don't use Commons Logging or Log4J.
</message>
<excludes>
<exclude>commons-logging:commons-logging</exclude>
<exclude>commons-logging:commons-logging-api</exclude>
<exclude>log4j:log4j</exclude>
</excludes>
</bannedDependencies>
</rules>
</configuration>
</execution>
<!-- Check that we're using commons-lang3 and not commons-lang -->
<execution>
<id>enforce-commons-lang3</id>
<goals>
<goal>enforce</goal>
</goals>
<configuration>
<rules>
<bannedDependencies>
<searchTransitive>false</searchTransitive>
<message>
Best practice is to use Commons Lang 3.x
</message>
<excludes>
<exclude>commons-lang:commons-lang</exclude>
</excludes>
</bannedDependencies>
</rules>
</configuration>
</execution>
<!-- Check dependency versions compatibility -->
<execution>
<id>enforce-upper-bounds</id>
<goals>
<goal>enforce</goal>
</goals>
<configuration>
<!-- TODO: Disabling since after the upgrade to the Enforcer plugin 1.3.1 (from 1.1) a whole bunch of
new violations were found and are failing the build. Put back when the build has been fixed to pass
-->
<skip>true</skip>
<rules>
<requireUpperBoundDeps />
</rules>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
<pluginManagement>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-checkstyle-plugin</artifactId>
<!-- Lock down plugin version for build reproducibility -->
<version>2.14</version>
<configuration>
<consoleOutput>true</consoleOutput>
<!-- We use this to disable checkstyle when the clover profile is executed since there's a
conflict between checkstyle and clover. Namely the clovered code doesn't pass our
checkstyle rules -->
<skip>${xwiki.checkstyle.skip}</skip>
</configuration>
</plugin>
<!-- Used to check/update license headers -->
<plugin>
<groupId>com.mycila</groupId>
<artifactId>license-maven-plugin</artifactId>
<!-- Lock down plugin version for build reproducibility -->
<version>2.6</version>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-remote-resources-plugin</artifactId>
<!-- Lock down plugin version for build reproducibility -->
<version>1.4</version>
</plugin>
<plugin>
<!-- Since 2.0-beta-9 maven-release-plugin uses remote tagging by default. Remote tagging implies that SCM
information is not fetched from the local working copy but from the SCM pom configuration. This forces
us to specify SCM configuration in every module which has its own lifecycle. Inheritance can't be used
for SCM configuration since a released parent pom contains SCM information about its tag and not about
the trunk. We could have globally set remoteTagging to false but we haven't since we prefer to follow
maven conventions as much as possible. -->
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-release-plugin</artifactId>
<!-- Lock down plugin version for build reproducibility -->
<version>2.5.1</version>
<configuration>
<!-- By default the release plugin will execute the "clean" and "verify" goals but won't perform an
"install". This is causing problems since several modules will fail to build during release:prepare.
See http://tinyurl.com/354vwe for more details. Thus we're forcing the execution of the "install"
goal. -->
<preparationGoals>clean install</preparationGoals>
<!-- Avoid site generation during the release:perform to speed up release process -->
<goals>deploy</goals>
<mavenExecutorId>forked-path</mavenExecutorId>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-clean-plugin</artifactId>
<!-- Lock down plugin version for build reproducibility -->
<version>2.6.1</version>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-source-plugin</artifactId>
<!-- Lock down plugin version for build reproducibility -->
<version>2.4</version>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-plugin-plugin</artifactId>
<!-- Lock down plugin version for build reproducibility -->
<version>2.9</version>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-install-plugin</artifactId>
<!-- Lock down plugin version for build reproducibility -->
<version>2.5.2</version>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<!-- Lock down plugin version for build reproducibility -->
<version>3.2</version>
<configuration>
<source>1.7</source>
<target>1.7</target>
</configuration>
<executions>
<!-- We need custom sourcepaths for our Component Annotation Process work
(See ComponentCheckerAnnotationProcessor.java). This is required because of
http://jira.codehaus.org/browse/MCOMPILER-122.
However note that IntelliJ IDEA doesn't honor custom sourcepaths, see
https://youtrack.jetbrains.com/issue/IDEA-133120, which means that you need to turn off
Annotation Processing in IDEA or IDEA will generate errors while building modules -->
<execution>
<id>default-compile</id>
<configuration>
<compilerArguments>
<sourcepath>${project.basedir}/src/main/java:${project.basedir}/src/main/resources</sourcepath>
</compilerArguments>
</configuration>
</execution>
<execution>
<id>default-testCompile</id>
<configuration>
<compilerArguments>
<sourcepath>${project.basedir}/src/test/java:${project.basedir}/src/test/resources</sourcepath>
</compilerArguments>
</configuration>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<!-- Lock down plugin version for build reproducibility -->
<version>2.16</version>
<!-- XWiki rule is to put test in *Test classes -->
<configuration>
<!-- We want to show nested stack traces to see what is the real problem when a test fails! -->
<trimStackTrace>false</trimStackTrace>
<includes>
<include>**/*Test.class</include>
</includes>
<systemProperties>
<property>
<name>xwiki.test.verifyRunningXWikiAtStart</name>
<value>${xwiki.test.verifyRunningXWikiAtStart}</value>
</property>
</systemProperties>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-resources-plugin</artifactId>
<!-- Lock down plugin version for build reproducibility -->
<version>2.7</version>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<!-- Lock down plugin version for build reproducibility -->
<version>2.5</version>
<configuration>
<!-- Add some useful information about the extension in the manifest file. -->
<archive>
<manifestEntries>
<XWiki-Extension-Id>${project.groupId}:${project.artifactId}</XWiki-Extension-Id>
</manifestEntries>
</archive>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-assembly-plugin</artifactId>
<!-- Lock down plugin version for build reproducibility -->
<version>2.5.3</version>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<!-- Lock down plugin version for build reproducibility -->
<version>2.10</version>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<!-- Lock down plugin version for build reproducibility -->
<version>2.6</version>
<configuration>
<!-- Add some useful information about the extension in the manifest file. -->
<archive>
<manifestEntries>
<XWiki-Extension-Id>${project.groupId}:${project.artifactId}</XWiki-Extension-Id>
</manifestEntries>
</archive>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-deploy-plugin</artifactId>
<!-- Lock down plugin version for build reproducibility -->
<version>2.8.2</version>
</plugin>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>aspectj-maven-plugin</artifactId>
<!-- Lock down plugin version for build reproducibility -->
<version>1.7</version>
<configuration>
<complianceLevel>1.7</complianceLevel>
<source>1.7</source>
<target>1.7</target>
</configuration>
<!-- Override so that we can use the AspectJ version we wish -->
<dependencies>
<dependency>
<groupId>org.aspectj</groupId>
<artifactId>aspectjtools</artifactId>
<version>${aspectj.version}</version>
</dependency>
</dependencies>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-antrun-plugin</artifactId>
<!-- Lock down plugin version for build reproducibility -->
<version>1.7</version>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-invoker-plugin</artifactId>
<!-- Lock down plugin version for build reproducibility -->
<version>1.8</version>
</plugin>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>xml-maven-plugin</artifactId>
<!-- Lock down plugin version for build reproducibility -->
<version>1.0</version>
</plugin>
<plugin>
<groupId>org.codehaus.izpack</groupId>
<artifactId>izpack-maven-plugin</artifactId>
<!-- Lock down plugin version for build reproducibility -->
<version>${izpack.version}</version>
</plugin>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>build-helper-maven-plugin</artifactId>
<!-- Lock down plugin version for build reproducibility -->
<version>1.7</version>
</plugin>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>exec-maven-plugin</artifactId>
<!-- Lock down plugin version for build reproducibility -->
<version>1.2.1</version>
</plugin>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>sablecc-maven-plugin</artifactId>
<!-- Lock down plugin version for build reproducibility -->
<version>2.2</version>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-project-info-reports-plugin</artifactId>
<!-- Lock down plugin version for build reproducibility -->
<version>2.4</version>
</plugin>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>clirr-maven-plugin</artifactId>
<!-- Lock down plugin version for build reproducibility -->
<version>2.6</version>
<executions>
<execution>
<id>clirr-check</id>
<goals>
<goal>check</goal>
</goals>
</execution>
</executions>
<configuration>
<comparisonVersion>${xwiki.clirr.previous.version}</comparisonVersion>
<skip>${xwiki.clirr.skip}</skip>
<excludes>
<exclude>**/internal/**</exclude>
</excludes>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-archetype-plugin</artifactId>
<!-- Lock down plugin version for build reproducibility -->
<version>2.2</version>
</plugin>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>findbugs-maven-plugin</artifactId>
<!-- Lock down plugin version for build reproducibility -->
<version>2.5.2</version>
</plugin>
<plugin>
<groupId>org.apache.felix</groupId>
<artifactId>maven-bundle-plugin</artifactId>
<!-- Lock down plugin version for build reproducibility -->
<version>2.3.7</version>
</plugin>
<plugin>
<groupId>com.atlassian.maven.plugins</groupId>
<artifactId>maven-clover2-plugin</artifactId>
<!-- Lock down plugin version for build reproducibility -->
<version>${clover.version}</version>
<configuration>
<license><![CDATA[qrQMuLFrILhIeRILrqhGBqjUrQQEnImixnpoFreoubGuqOa
mj2Kjoh2sXZcCMFBWOhe<dGh2L053ktz00HxawUp94OiFmK
rmnrUtrrrnMPPpNRrOOwXoNPnRqQqRMmPOsWsSsvVtTPqQP
rnmqmUUnptsnqpommmmmUUnptsnqpommmmmUUONfhfUUnmm
mm
]]></license>
<!-- For some reason there's currently a problem in the Rendering Include Macro test execution when
IncludeMacroTest is clovered. Needs to be investigated. -->
<includesTestSourceRoots>false</includesTestSourceRoots>
</configuration>
</plugin>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>cobertura-maven-plugin</artifactId>
<!-- Lock down plugin version for build reproducibility -->
<version>2.5.1</version>
</plugin>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>sonar-maven-plugin</artifactId>
<!-- Lock down plugin version for build reproducibility -->
<version>2.0</version>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-gpg-plugin</artifactId>
<!-- Lock down plugin version for build reproducibility -->
<version>1.6</version>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-javadoc-plugin</artifactId>
<!-- Lock down plugin version for build reproducibility -->
<version>2.10.1</version>
<configuration>
<!-- Always exclude the internal package since it's not user-public -->
<excludePackageNames>*.internal.*</excludePackageNames>
<!-- Make sure javadoc has enough memory -->
<maxmemory>300m</maxmemory>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-site-plugin</artifactId>
<!-- Lock down plugin version for build reproducibility -->
<version>3.3</version>
<!-- Site Plugin doesn’t automatically pull the Apache Wagon Dav implementation which is needed for
site:deploy goal when using Dav protocol. -->
<dependencies>
<dependency>
<groupId>org.apache.maven.wagon</groupId>
<artifactId>wagon-webdav-jackrabbit</artifactId>
<version>2.6</version>
</dependency>
</dependencies>
<configuration>
<reportPlugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-project-info-reports-plugin</artifactId>
<version>2.4</version>
<configuration>
<!-- Since contacting the Maven Repositories can take a very long time, tell the plugin not to display
the repository locations of the dependencies in the report. -->
<dependencyLocationsEnabled>false</dependencyLocationsEnabled>
</configuration>
<reports>
<report>summary</report>
<report>index</report>
<report>dependencies</report>
<report>dependency-convergence</report>
<report>mailing-list</report>
<report>issue-tracking</report>
<report>scm</report>
</reports>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-javadoc-plugin</artifactId>
<version>2.9.1</version>
<configuration>
<!-- Always exclude the internal package since it's not user-public -->
<excludePackageNames>*.internal.*</excludePackageNames>
<!-- Make sure javadoc has enough memory -->
<maxmemory>300m</maxmemory>
</configuration>
<!-- Don't generate test javadoc -->
<reports>
<report>javadoc</report>
</reports>
</plugin>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>cobertura-maven-plugin</artifactId>
<version>2.5.1</version>
</plugin>
</reportPlugins>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-shade-plugin</artifactId>
<!-- Lock down plugin version for build reproducibility -->
<version>2.2</version>
</plugin>
<plugin>
<groupId>org.jacoco</groupId>
<artifactId>jacoco-maven-plugin</artifactId>
<!-- Lock down plugin version for build reproducibility -->
<version>0.7.2.201409121644</version>
</plugin>
<plugin>
<groupId>com.github.searls</groupId>
<artifactId>jasmine-maven-plugin</artifactId>
<!-- Lock down plugin version for build reproducibility -->
<version>1.3.1.5</version>
<!-- Turn off logging in the console since some non-important errors (duh!) make Jenkins fail the build.
For example:
[INFO] Executing Jasmine Specs
[ERROR] Unexpected exception occurred while parsing HTML snippet
[ERROR] runtimeError: message=[Unexpected exception occurred while parsing HTML snippet:
input name="x"] sourceName=[file:/home/hudsonagent/hudson_root/workspace/xwiki-platform/
xwiki-platform-core/xwiki-platform-web/target/jasmine/src/js/prototype/prototype.js] line=[2084]
lineSource=[null] lineOffset=[0]
-->
<dependencies>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>jcl-over-slf4j</artifactId>
<version>${slf4j.version}</version>
</dependency>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-nop</artifactId>
<version>${slf4j.version}</version>
</dependency>
</dependencies>
</plugin>
</plugins>
</pluginManagement>
</build>
<profiles>
<profile>
<!-- Profile used when the release plugin executes. We want javadocs and source jars to be released
+ ensure we sign files using GPG. -->
<id>release</id>
<activation>
<property>
<!-- This property is automatically defined by the Maven release plugin when executing
a release. Thus this profile will be automatically enabled when releasing -->
<name>performRelease</name>
<value>true</value>
</property>
</activation>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-source-plugin</artifactId>
<executions>
<execution>
<id>attach-sources</id>
<goals>
<goal>jar</goal>
</goals>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-javadoc-plugin</artifactId>
<executions>
<execution>
<id>attach-javadocs</id>
<goals>
<goal>jar</goal>
</goals>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-enforcer-plugin</artifactId>
<executions>
<execution>
<id>enforce-java</id>
<goals>
<goal>enforce</goal>
</goals>
<configuration>
<rules>
<requireJavaVersion>
<message>You must release with Java 7!</message>
<version>[1.7, 1.8)</version>
</requireJavaVersion>
</rules>
</configuration>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-gpg-plugin</artifactId>
<executions>
<execution>
<id>sign-artifacts</id>
<phase>verify</phase>
<goals>
<goal>sign</goal>
</goals>
</execution>
</executions>
</plugin>
<!-- Because of http://jira.codehaus.org/browse/MJAVADOC-329 we need to find a workaround to create a Javadoc
JAR to satisfy the Maven Central Repository requirements. We do this by creating an apidocs/ dir in the
target directory.
Note that even though this "hack" is only needed for java projects having all their sources in the
internal packages we put it here in the top level POM to not have to duplicate it at lots of places. -->
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-antrun-plugin</artifactId>
<executions>
<execution>
<!-- The Javadoc JAR plugin runs in the package phase so we need a phase before that -->
<phase>generate-resources</phase>
<configuration>
<target>
<mkdir dir="${project.build.directory}/apidocs" />
</target>
</configuration>
<goals>
<goal>run</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
</profile>
<!-- To generate Clover reports, see http://dev.xwiki.org/xwiki/bin/view/Community/Testing#HTestCoverage -->
<profile>
<id>clover</id>
<properties>
<!-- We need to skip checkstyle execution since otherwise it conflicts with Clover -->
<xwiki.checkstyle.skip>true</xwiki.checkstyle.skip>
<!-- Skip Clirr since we don't need it when computing test coverage and it speeds up the build not to run it -->
<xwiki.clirr.skip>true</xwiki.clirr.skip>
<!-- Skip Enforcer since we don't need it for coverage and it speeds up the build not to run it -->
<xwiki.enforcer.skip>true</xwiki.enforcer.skip>
</properties>
<dependencyManagement>
<dependencies>
<!-- Needed when using Clover for runtime execution of integration tests -->
<dependency>
<groupId>com.cenqua.clover</groupId>
<artifactId>clover</artifactId>
<version>3.1.6</version>
</dependency>
</dependencies>
</dependencyManagement>
</profile>
<!-- Profile for m2eclipse which is used to tell m2eclipse to use a different output directory -->
<profile>
<id>m2e</id>
<properties>
<m2BuildDirectory>target-eclipse</m2BuildDirectory>
</properties>
<activation>
<property>
<name>m2e.version</name>
</property>
</activation>
<build>
<directory>${m2BuildDirectory}</directory>
</build>
</profile>
<!-- Profile for QA verifications that takes time -->
<profile>
<id>quality</id>
<properties>
<!-- Default Jacoco Instruction Ratio. We use 100% to force each module to define its
own ratio. Note that good values are above 70%. -->
<xwiki.jacoco.instructionRatio>1.00</xwiki.jacoco.instructionRatio>
</properties>
<build>
<plugins>
<!-- Fail the build if the test coverage is below a given value. -->
<plugin>
<groupId>org.jacoco</groupId>
<artifactId>jacoco-maven-plugin</artifactId>
<executions>
<execution>
<id>jacoco-prepare</id>
<goals>
<goal>prepare-agent</goal>
</goals>
</execution>
<execution>
<id>jacoco-check</id>
<goals>
<goal>check</goal>
</goals>
</execution>
</executions>
<configuration>
<rules>
<rule>
<limits>
<limit>
<counter>INSTRUCTION</counter>
<minimum>${xwiki.jacoco.instructionRatio}</minimum>
</limit>
</limits>
</rule>
</rules>
</configuration>
</plugin>
</plugins>
</build>
</profile>
<profile>
<!-- Run full coverage for all modules in the current maven reactor build by generating the Jacoco result file
in one common location and appending data to it. -->
<id>coverage</id>
<build>
<plugins>
<plugin>
<groupId>org.jacoco</groupId>
<artifactId>jacoco-maven-plugin</artifactId>
<executions>
<execution>
<id>jacoco-prepare</id>
<goals>
<goal>prepare-agent</goal>
</goals>
</execution>
</executions>
<configuration>
<destFile>${xwiki.jacoco.itDestFile}</destFile>
<append>true</append>
</configuration>
</plugin>
</plugins>
</build>
</profile>
</profiles>
<distributionManagement>
<site>
<id>nexus.xwiki.org</id>
<url>dav:http://nexus.xwiki.org/nexus/content/sites/site/</url>
</site>
<repository>
<id>nexus.xwiki.org</id>
<name>XWiki Maven Remote Repository for Releases</name>
<url>http://nexus.xwiki.org/nexus/content/repositories/releases/</url>
</repository>
<snapshotRepository>
<id>nexus.xwiki.org</id>
<name>XWiki Maven Development Repository for Snapshots</name>
<url>http://nexus.xwiki.org/nexus/content/repositories/snapshots/</url>
</snapshotRepository>
</distributionManagement>
<modules>
<!-- Sorted Alphabetically -->
<module>xwiki-commons-core</module>
<module>xwiki-commons-pom</module>
<module>xwiki-commons-tools</module>
</modules>
</project>
![swh spinner](/static/img/swh-spinner.gif)
Computing file changes ...