Update comments on current status of xalan-test integration.

Author: kubycsolutions

integration-tests/pom.xml

@@ -61,31 +61,43 @@
         </configuration>
       </plugin>
 
-      <!-- Invoke sibling xalan-test project for conformance tests.
-           
-           Warning: Some of the tasks and tools written for xalan-test
+      <!-- Invoke sibling xalan-test project for conformance tests?
+           Ideally we want that done before packaging, so a current
+           conformance run (at least the essential targets) is run
+           befroe the tests and results are bundled into the
+           source distribution archive file.
+
+           Unfortunately there are a number of complications.
+
+           1) The right time to run this would be just before the package
+           phase, to ensure the most current results are included in
+           that package. Unfortunately as currently written the tests
+           are taking advantage of packaging to avoid having to
+           specify the version number as part of the jarfile
+           names. Simplest fix may be to change the xalan-test
+           classpaths for xalan to reference our target/*
+           (the only form of wildcard permitted in classpaths,
+           acceptable here since it's only be the xalan products),
+           or to have the copy-dependencies run in pre-package.
+
+           2) Some of the tasks and tools written for xalan-test
            assumed they were being executed from the xalan-test/
            directory, and the maven-antrun-plugin does not seem to
            offer a good way to change "current directory" before
            running, no matter whether <ant> or <subant> is used.
            Similarly, some of the classpath setup for xalan-test was
            being done in the front-end build.* scripts rather than in
-           the actual ant build.xml.
+           the actual ant build.xml. 
 
            We could/should at some point rationalize the test driver
-           But exec:exec does appear to allow setting <workingdirectory>, 
-           and adding to the classpath via -lib.
-
-           It isn't as pretty as using the <antrun> task would be.
-           But it appears to do the job.
+           But exec:exec does appear to allow setting
+           <workingdirectory>, and adding to the classpath via
+           -lib. It isn't as pretty as using the <antrun> task would
+           be.  But it appears to do the job.
 
-           NOTE TOO: If we want to include the results of this test in
-           the source distribution archives, this needs to run before
-           "package". THAT IS NOT WHAT IS CURRENTLY HAPPENING.
-	   Maven only supports dependencies at the module level,
-	   with phase ordering only guaranteed within each module,
-	   so the fix appears to be to break this out into
-	   another module and make distribution depend upon it
+           It is actually unclear that this automatic xalan-test run
+           was being done by the ant build. If it wasn't, we could
+           defer this... but it's desirable for source packaging if/when.
       -->
       <plugin>
         <groupId>org.codehaus.mojo</groupId>
@@ -94,7 +106,7 @@
         <executions>
           <execution>
             <id>xalan-test attempt</id>
-            <phase>test</phase>
+            <phase>pre-</phase>
             <goals>
               <goal>exec</goal>
             </goals>

pom.xml

@@ -533,6 +533,11 @@
         <artifactId>xalansamples</artifactId>
         <version>${project.version}</version>
       </dependency>
+      <dependency>
+        <groupId>xalan</groupId>
+        <artifactId>integration-test</artifactId>
+        <version>${project.version}</version>
+      </dependency>
 
       <!-- For javadoc generation only. Which of the two 'xalan2jtaglet*'
            artifacts is used, is determined automatically by Maven profiles