Skip to content

Commit a0b2294

Browse files
kubycsolutionskubycsolutions
committed
For Xalanj-2711: Document approach, and issues, if we want to automatically
invoke xalan-test to smoketest builds (and to ensure source packaging gets current test results). Add xalan-test invocation to integration-tests. Not quite cooked yet. Move xalan-test to verify phase? Try to update autobuild for new xalan-test via validate Revert "Try to update autobuild for new xalan-test via validate" ... Seems I don't have permission for that. Sigh. This reverts commit 6e8d520. Dithering between <ant> and <subant> tasks. There doesn't seem to be any advantage in the former; I had been hoping it would set current directory to avoid fixing defaults in xalan-test. It isn't the prettiest, but I have found a way to cleanly build and run ../xalan-test from within the mvn build. That's highly desirable if we're going to ship the testcases with the source archive, since it captures the results of the latest run of the tests as evidence of acceptability. I am not yet addressing how xalan-test gets checked out, other than presumably throwing an error if it hasn't been. Maven execution ordering will mean distribution must be dependent upon integration-tests... or the conformance tests much be a separate module which distribution depends upon. WORK NEEDED. Update comments on current status of xalan-test integration. Comments. ISSUE: Xalan-test is currently relying on our having run the package target to avoid version numbers in jarfile names, which keeps test from running successfully pre-package... but that's when it _wants_ to run, so package can copy most recent results into the source archive as documentation. Easiest fix would be to change xalan-test to use ../xalan-java/* (the only form of wildcard that Java classpaths support). Assuming we do decided to fix this; xalan-java's ant build did *not* always run smoketests. Disable the cross-call to xalan-test pending decision on that.
1 parent 5138cc2 commit a0b2294

File tree

2 files changed

+103
-1
lines changed

2 files changed

+103
-1
lines changed

‎integration-tests/pom.xml‎

Lines changed: 88 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -49,7 +49,6 @@
4949
<postBuildHookScript>verify</postBuildHookScript>
5050
<localRepositoryPath>${project.build.directory}/local-repo</localRepositoryPath>
5151
<goals>
52-
<goal>clean</goal>
5352
<goal>test</goal>
5453
</goals>
5554
<settingsFile>src/it/settings.xml</settingsFile>
@@ -61,6 +60,94 @@
6160
<!--<invokerTest>VersionCheck_*Boot*</invokerTest>-->
6261
</configuration>
6362
</plugin>
63+
64+
<!-- Invoke sibling xalan-test project for conformance tests?
65+
The Ant build for Xalan did *not* do so automagically,
66+
though it had convenience targets for doing so an
67+
for warning if the test suite was not where it was
68+
expected to be.
69+
70+
Ideally we want that done before packaging, so a current
71+
conformance run (at least the essential targets) is run
72+
befroe the tests and results are bundled into the
73+
source distribution archive file.
74+
75+
Unfortunately there are a number of complications.
76+
77+
1) The right time to run this would be just before the package
78+
phase, to ensure the most current results are included in
79+
that package. Unfortunately as currently written the tests
80+
are taking advantage of packaging to avoid having to
81+
specify the version number as part of the jarfile
82+
names. Simplest fix may be to change the xalan-test
83+
classpaths for xalan to reference our target/*
84+
(the only form of wildcard permitted in classpaths,
85+
acceptable here since it's only be the xalan products),
86+
or to have the copy-dependencies run in pre-package.
87+
88+
2) Some of the tasks and tools written for xalan-test
89+
assumed they were being executed from the xalan-test/
90+
directory, and the maven-antrun-plugin does not seem to
91+
offer a good way to change "current directory" before
92+
running, no matter whether <ant> or <subant> is used.
93+
Similarly, some of the classpath setup for xalan-test was
94+
being done in the front-end build.* scripts rather than in
95+
the actual ant build.xml.
96+
97+
We could/should at some point rationalize the test driver
98+
But exec:exec does appear to allow setting
99+
<workingdirectory>, and adding to the classpath via
100+
-lib. It isn't as pretty as using the <antrun> task would
101+
be. But it appears to do the job.
102+
103+
Since the ant build packaged but did not normally run the
104+
tests (or check for a successful run having been done), we
105+
don't actually have to do this right now. It's desirable if
106+
the test source includes proof of recent run against that
107+
source, but deferrable.
108+
-->
109+
110+
<!-- <plugin> -->
111+
<!-- <groupId>org.codehaus.mojo</groupId> -->
112+
<!-- <artifactId>exec-maven-plugin</artifactId> -->
113+
<!-- <version>3.5.1</version> -->
114+
<!-- <executions> -->
115+
<!-- <execution> -->
116+
<!-- <id>xalan-test attempt</id> -->
117+
<!-- <phase>pre-package</phase> -->
118+
<!-- <goals> -->
119+
<!-- <goal>exec</goal> -->
120+
<!-- </goals> -->
121+
<!-- </execution> -->
122+
<!-- </executions> -->
123+
<!-- <configuration> -->
124+
<!-- <executable>ant</executable> -->
125+
<!-- <workingDirectory>../../xalan-test</workingDirectory> -->
126+
<!-- <addOutputToClasspath>true</addOutputToClasspath> -->
127+
<!-- <addResourcesToClasspath>true</addResourcesToClasspath> -->
128+
<!-- <arguments> -->
129+
<!-- <!-\- Use -lib to make sure we're on Ant's classpath -->
130+
<!-- (something that the front-end xalan-test/build -->
131+
<!-- scripts we doing). This arguably should not be -->
132+
<!-- needed (especially now that we should no longer -->
133+
<!-- need endorsed or boot path overrides), but without -->
134+
<!-- it the tests may not resolve the XSLTC transformer -->
135+
<!-- factory class. Yes, that means the xalan-test ant -->
136+
<!-- build is sloppy. We knew that. -->
137+
<!-- -\-> -->
138+
<!-- <argument>-lib</argument> -->
139+
<!-- <argument>../xalan-java/build:../build:../xalan-java/lib/endorsed:../lib/endorsed</argument> -->
140+
141+
<!-- <argument>clean</argument> -->
142+
<!-- <argument>jar</argument> -->
143+
<!-- <argument>extensions.classes</argument> -->
144+
<!-- <argument>smoketest</argument> -->
145+
<!-- <argument>apitest</argument> -->
146+
<!-- <argument>conf.xsltc</argument> -->
147+
<!-- </arguments> -->
148+
<!-- </configuration> -->
149+
<!-- </plugin> -->
150+
64151
</plugins>
65152
</build>
66153
</project>

‎pom.xml‎

Lines changed: 15 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -413,6 +413,16 @@
413413
</executions>
414414
</plugin>
415415

416+
<!-- Exec is currently our best bet for invoking the separate
417+
xalan-test project's ant built, due to sensitivities that
418+
currently has upon workingdir and classpath. See
419+
integration-tests/
420+
-->
421+
<plugin>
422+
<groupId>org.codehaus.mojo</groupId>
423+
<artifactId>exec-maven-plugin</artifactId>
424+
<version>3.5.1</version>
425+
</plugin>
416426
</plugins>
417427
</pluginManagement>
418428

@@ -523,6 +533,11 @@
523533
<artifactId>xalansamples</artifactId>
524534
<version>${project.version}</version>
525535
</dependency>
536+
<dependency>
537+
<groupId>xalan</groupId>
538+
<artifactId>integration-test</artifactId>
539+
<version>${project.version}</version>
540+
</dependency>
526541

527542
<!-- For javadoc generation only. Which of the two 'xalan2jtaglet*'
528543
artifacts is used, is determined automatically by Maven profiles

0 commit comments

Comments
 (0)