corrections to documentation.
authorErik Brakkee <erik@brakkee.org>
Tue, 6 Jul 2010 20:21:15 +0000 (20:21 +0000)
committerErik Brakkee <erik@brakkee.org>
Tue, 6 Jul 2010 20:21:15 +0000 (20:21 +0000)
`

test/enterprise/src/main/java/org/wamblee/support/persistence/package-info.java
test/enterprise/src/site/xdoc/index.xml

index 1ea78e255d6e9e6bb1c712431c4dac3085637de0..979dde6f7c0189c5d4a53f709d610403218de996 100644 (file)
@@ -42,7 +42,7 @@
  * </ul>
  * 
  * <p>
- *   See the <a href="#design-overview">design overview</a> for a an overview of the design.  
+ *   See also the <a href="#design-overview">design overview</a>.  
  * </p>
  * 
  * <a name="db-basic">
  *      Database db = DatabaseBuilder.getDatabase();
  *      DataSource dataSource = db.start();
  * </pre>
+ * <p>
  * If nothing is specified in the user's environment, an inmemory database is started (derby).
- * Using the datasource is just standard JDBC now. 
- * Stopping the database
+ * Using the datasource is just standard JDBC now.
+ * </p>
+ * <p>
+ * After a test it is good practice to stop the database:
+ * </p>
  * <pre>
  *      db.stop();
  * </pre>
@@ -75,7 +79,7 @@
  * <p>
  * However, the most convenient way to set the capabilities is usually to set a system property or environment 
  * variable see the javadocs of {@link DatabaseBuilder}. and 
- * specifically {@link DatabaseBuilder#DB_CAPABILITIES_PROP}
+ * specifically <code>DatabaseBuilder.DB_CAPABILITIES_PROP</code>
  * </p>
  * 
  * 
  *   <h2>Using DB Unit in your tests</h2>
  * </a>
  * 
- * <p>To work with <a href="http://dbunit.org">DBUnit</a>, {@link DatabaseUtils#createDbTester(org.dbunit.dataset.filter.ITableFilterSimple)}
+ * <p>To work with <a href="http://dbunit.org">DBUnit</a>, 
+ * <code>DatabaseUtils#createDbTester(org.dbunit.dataset.filter.ITableFilterSimple)</code>
  * must be used passing it in the tables to use in the form of a {@link org.dbunit.dataset.filter.ITableFilterSimple}
  * object. </p>
  * 
  *    want to test. 
  * </p>
  * <p>Second step is to make sure that all entities are listed explicitly in your
- *    <pre>persistence.xml</pre>. Currently, class path scanning appears to fail when
+ *    <code>persistence.xml</code>. Currently, class path scanning appears to fail when
  *    run from junit. 
  *    Specifying all entities explicitly is not necessarily a bad thing as it is also more efficient. 
  * </p>
  * get them directly from the <code>JPATester</code> after initializing it: 
  * <pre>
  *      builder = jpaTester.getJpaBuilder();
- *      dbtester = jpaTester.getDbUtils().createDbTester(new MyTables());
  *      dbutils = jpaTester.getDbUtils();
+ *      dbtester = dbutils.createDbTester(new MyTables());
  * </pre>
  * 
  * <a name="db-jpa-services">
index 429c8ea3c7170edd79fc29e0807f5a0697f934a9..8f58bf4fc362733a8881b33ccd9c13241b48e876 100644 (file)
@@ -31,7 +31,8 @@
         <li>Different JPA providers can, in general, not be used within the same application. (an
           exception is of course an OSGI environment when JPA is used as per the OSGI enterprise
           spec). </li>
-        <li>You also want to define your own specific JPA version. </li>
+        <li>The specific JPA implementation and version to use <em>must</em> be determined by you
+          and not by the test support library. </li>
       </ul>
       
       <subsection name="The general JPA test support library">