This page provides information about the commons-parent pom.xml
Commons components use Maven as their primary build system and commons-parent is the parent pom for the components' Maven build.
Using a parent pom reduces the build configuration required for each individual component and standardizes the builds accross commons components.
The following is a list of the main build features provided by commons-parent:
The following is a list of the main release features provided by commons-parent through the rc and release profiles.
Additionally the RAT (release audit) report is automatically produced when generating a component's site. The RAT report checks the source files for appropriate License Headers.
The following is a list of the main site features provided by commons-parent:
commons-parent configures the source and target options in the maven-compiler-plugin to use the ${maven.compile.source} and ${maven.compile.target} properties respectively. [NOTE: the Maven compiler plugin defaults to ${maven.compiler.source} and ${maven.compiler.target}; however for some (historical?) reason the Commons Parent POM has always used ".compile." rather than ".compiler." See https://issues.apache.org/jira/browse/COMMONSSITE-69].
So, for example, to configure a component to have source/target set to 1.4 add the following lines to the component's pom.xml:
<properties>
<maven.compile.source>1.4</maven.compile.source>
<maven.compile.target>1.4</maven.compile.target>
</properties>
In order to help check what source/target options were used when building a release, the property values used to configure the source/target options in the maven-compiler-plugin (i.e. ${maven.compile.source} and ${maven.compile.target}) are also written out to the component jar's MANIFEST.MF file with the following values:
X-Compile-Source-JDK: 1.4
X-Compile-Target-JDK: 1.4
Using the target option ensures that the .class file format is compatible with the required Java version - but it does not prevent/catch the use of methods/classes which were introduced in later Java versions (because the build will use the current Java libraries by default). The only way to ensure that components don't accidentally use classes/methods from a later version of Java is to compile and test using actual Java versions.
For this reason commons-parent provides profiles for compiling/testing under different Java versions:
In order for these profiles to work, you need to configure the JAVA_1_3_HOME, JAVA_1_4_HOME, JAVA_1_5_HOME and JAVA_1_6_HOME properties in your settings.xml file (or as environment variables or even command-line properties). See here for details. Each property should be set to the directory where the relevant version of the JDK is installed.
Note: the maven-bundle-plugin outputs all property values which start with a capital letter as headers to the jar's MANIFEST.MF file. The commons-parent pom uses the <_removeheaders> instruction to suppress the specific JAVA_* properties used by the pom.
To ensure that the properties are only present if they are actually needed, you can define the property in the relevant profile in your settings.xml, for example:
<settings>
<profiles>
<profile>
<id>java-1.3</id>
<properties>
<JAVA_1_3_HOME>C:\j\jdk1.3.1_18</JAVA_1_3_HOME>
</properties>
</profile>
<profile>
<id>java-1.4</id>
<properties>
<JAVA_1_4_HOME>C:\j\jdk1.4.2_19</JAVA_1_4_HOME>
</properties>
</profile>
<profile>
<id>java-1.5</id>
<properties>
<JAVA_1_5_HOME>C:\j\jdk1.5.0_22</JAVA_1_5_HOME>
</properties>
</profile>
<profile>
<id>java-1.6</id>
<properties>
<JAVA_1_6_HOME>C:\j\jdk1.6.0_17</JAVA_1_6_HOME>
</properties>
</profile>
</profiles>
</settings>
(Since the values are the locations of the Java installations on your local machine, they are unlikely to change frequently and using the settings.xml file will be the most convenient).
Once you have configured those properties you can, for example, compile and test with Java 1.4 using the following command:
mvn -Pjava-1.4 clean test
In order to use a Commons component (or any libaray) in an OSGi container (for example Apache Felix) then OSGi metadata needs to be included in the MANIFEST.MF file of the component's jar.
commons-parent is configured to automatically add the OSGi metadata to the component jar's MANIFEST.MF using the maven-bundle-plugin when the package phase is executed:
mvn package
Most components only need to configure the <commons.componentid> property in their pom.xml in the following way:
<properties>
<commons.componentid>beanutils</commons.componentid>
</properties>
There are a number of other OSGi properties in the commons-parent pom.xml which are used to configure the maven-bundle-plugin. These have sensible defaults, but can be overriden in a component's pom.xml if required. These are:
commons-parent contains some java profiles to compile/test using different versions of Java. See here for details of using the Java profiles.
commons-parent contains an rc profile for producing release candidates.
Running the following command will, in addition to creating the jar as normal, will also:
mvn -Prc package
Running the following command will, as well as doing producing everything specified above for the package command, also sign the artifacts and create checksums (in local m2 repo):
mvn -Prc install
commons-parent contains an release profile for producing releases. This is the same as the rc profile except the repository and snapshotRepository locations are different.
Running the following command will, in addition to creating the jar as normal, will also:
mvn -Prelease package
commons-parent contains a trunks-proper profile with the components set up as <modules>. This is a convenience profile so that Maven commands can be run for all components.
N.B. This profile works with http://svn.apache.org/repos/asf/commons/trunks-proper/ which, you need to check out first (it pulls in the trunks of the components using an svn:externals property - see here for more details).
For example, if the template for the download page was changed, you could re-generate the download pages for all components using the following command:
mvn -Ptrunks-proper commons:download-page
...or to test all components:
mvn -Ptrunks-proper clean test
commons-sandbox-parent contains a trunks-sandbox profile with the sandbox components set up as <modules>. This is a convenience profile so that Maven commands can be run for all sandbox components.
N.B. This profile works with http://svn.apache.org/repos/asf/commons/trunks-sandbox/ which, you need to check out first (it pulls in the trunks of the sandbox components using an svn:externals property - see here for more details).
For example, if the template for the sandbox issue tracking page was changed, you could re-generate the issue tracking pages for all sandbox components using the following command:
mvn -Ptrunks-sandbox commons:sandbox-jira-page
...or to test all sandbox components:
mvn -Ptrunks-sandbox clean test