commons-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject svn commit: r922619 - /commons/proper/commons-site/src/site/xdoc/commons-parent-pom.xml
Date Sat, 13 Mar 2010 17:28:49 GMT
Author: sebb
Date: Sat Mar 13 17:28:49 2010
New Revision: 922619

More info on JAVA props and Bnd


Modified: commons/proper/commons-site/src/site/xdoc/commons-parent-pom.xml
--- commons/proper/commons-site/src/site/xdoc/commons-parent-pom.xml (original)
+++ commons/proper/commons-site/src/site/xdoc/commons-parent-pom.xml Sat Mar 13 17:28:49 2010
@@ -227,14 +227,16 @@
-      <subsection name="Testing with different Java versions">
+      <subsection name="Compiling / Testing with different Java versions">
           Using the <i>target</i> option ensures that the <code>.class</code>
file format is compatible with
-          the required Java version - but it doesn't not prevent/catch the use of methods/classes
which were
-          introduced in later Java versions. The only way to do that is to compile and test
using actual
-          Java versions.
+          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 the coded does not accidentally use classes/methods
from a different (later)
+          version of Java is to compile and test using actual Java versions.
+          For this reason
           <a href="">commons-parent</a>
           provides <i>profiles</i> for compiling/testing under different Java
@@ -252,10 +254,13 @@
           for details. Each property should be set to the <code>directory</code>
where the relevant version of the JDK is installed.
-          Unfortunately the <a href="">maven-bundle-plugin</a>
-          will output these property values to the jar's <code>MANIFEST.MF</code>
file. You can avoid this
-          by defining the property in the profile its used in in your <code>settings.xml</code>,
for example:
+          Note that the <a href="">maven-bundle-plugin</a>
+          copies will output all property values which start with a capital letter as headers
in jar's <code>MANIFEST.MF</code> file.
+          The commons-parent pom uses the &lt;_removeheaders&gt; instruction to suppress
the specific JAVA_* properties used by the pom.
+        </p>
+        <p>
+          To ensure that the properties are only defined if they are actually needed, you
+          define the property in the relevant profile in your <code>settings.xml</code>,
for example:
@@ -307,7 +312,7 @@
       <subsection name="OSGi Metadata">
           In order to use a Commons component (or any libaray) in an 
-          <a href="">OSGi</a> conatiner (for example
+          <a href="">OSGi</a> container (for example
           <a href="">Apache Felix</a>) then OSGi
           <i>metadata</i> needs to be included in the <code>MANIFEST.MF</code>
           file of the component's <i>jar</i>.
@@ -354,6 +359,8 @@
              <li>The <b><code>&lt;commons.osgi.dynamicImport&gt;</code></b>
property configures the
+             <li>As mentioned above, the <b><code>&lt;_removeheaders&gt;</code></b>
instruction is used 
+                 to prevent the known JAVA_1_*_HOME properties from appearing as headers
in the manifest.</li>

View raw message