commons-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From s...@apache.org
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

URL: http://svn.apache.org/viewvc?rev=922619&view=rev
Log:
More info on JAVA props and Bnd

Modified:
    commons/proper/commons-site/src/site/xdoc/commons-parent-pom.xml

Modified: commons/proper/commons-site/src/site/xdoc/commons-parent-pom.xml
URL: http://svn.apache.org/viewvc/commons/proper/commons-site/src/site/xdoc/commons-parent-pom.xml?rev=922619&r1=922618&r2=922619&view=diff
==============================================================================
--- 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 @@
         </source>
       </subsection>
 
-      <subsection name="Testing with different Java versions">
+      <subsection name="Compiling / Testing with different Java versions">
         <p>
           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.
         </p>
         <p>
+          For this reason
           <a href="http://svn.apache.org/repos/asf/commons/proper/commons-parent/trunk/pom.xml">commons-parent</a>
           provides <i>profiles</i> for compiling/testing under different Java
versions:
         </p>
@@ -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.
         </p>
         <p>
-          Unfortunately the <a href="http://felix.apache.org/site/apache-felix-maven-bundle-plugin-bnd.html">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="http://felix.apache.org/site/apache-felix-maven-bundle-plugin-bnd.html">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
can
+          define the property in the relevant profile in your <code>settings.xml</code>,
for example:
         </p>
         <source><![CDATA[
         <settings>
@@ -307,7 +312,7 @@
       <subsection name="OSGi Metadata">
         <p>
           In order to use a Commons component (or any libaray) in an 
-          <a href="http://www.osgi.org/">OSGi</a> conatiner (for example
+          <a href="http://www.osgi.org/">OSGi</a> container (for example
           <a href="http://felix.apache.org/">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 @@
                 <b><code>&lt;Import-Package&gt;</code></b>
instruction</li>
              <li>The <b><code>&lt;commons.osgi.dynamicImport&gt;</code></b>
property configures the
                 <b><code>&lt;DynamicImport-Package&gt;</code></b>
instruction</li>
+             <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>
           </ul>
         </p>
       </subsection>



Mime
View raw message