Maven migration, refactored, plus maven build changes since then. #110
Conversation
…erializer package. Late moves applied now.
…p that from running in the parent.
…ying the jarnames. Bad news: Still creating/stepping on ../build. Maven conditionals are hairy...
…bility for xalan-test etc.
…on output_xml.properties being in the original location. We can change that, but Not Now; reverting that move.
|
In the absense of review: Given that the executable build appears to be correct, I'm looking at subtler differences betweeen the Maven and Ant In the jarfile for the samples
Should I fix the Maven build to produce these isolated XSLTC sample jar/war files, or is nobody ever really going to care? (Arguably I should produce the .war file, at least, since it needs data files/directory structure not included in the overall samples jarfile.) |
|
Another current difference between the ant and maven builds is how the "distribution" archives are created. Currently, the ant build generates both zip and .tar.gz versions of xalan-j_version_number-bin.tar and xalan-j_version_number-src.tar. The Ant source collection puts everything under a top-level xalan-j_version_number/ directory, and pulls xalan-test in as a subdirectory. The intent appears to be to facilitate atomic distribution, build, and test when fetch from git is not practical. Maven instead is currently producing a .sources.jar for each module, and is not including the tests in any of them (though it will do so if/when we migrate xalan-test into xalan_java/test). Is there still a need for a source distribution collection? The Ant bin collection does not include a copy of the tests, but does bundle xalan and serializer under a xalan-j_version_number/ directory, and includes documentation and SOURCE of the samples -- in other words, it's basically the build output minus compilation of the samples. It does not bundle the tests. Maven is not currently producing an equivalent. Is there still a need for this? |
…hould upload src jars too...?
…ectory. Gather sources? Distribution archives?
jkesselm
force-pushed
the
xalan-java-mvn-refactored
branch
from
146de7f
to
b2eaeed
Compare
…t kill it just yet.
… and expand them at build time, but mvn doesn't have a simple untar (except via antrun or exec) and the're already checked in expanded, so...
|
Maven build now copies Other differences noted above persist: tests are not folded into this set of sources, single samples.jar (rename xalansamples?), no xalanservlet.war. Rechecking jarfile contents to make sure everything still matches outside of those quibbles. Still seeking consensus from the rest of Mission Control. |
…dress keeping this and poms in synch.
…nus tests for not.
…easonable result for src, though I want it in the ant-alike build/ directory. The bin assembly is blowing up on me and is checked in disabled.
…ror. Comment out temporarily.
…ter way to do this.
… unnecessary; I'm being paranoid.
… its .war. Some file updates required to reflect properly scoped java project. Some indentation rationalized.
…I have a better sense of how Maven behaves. Still need to sanity-check contents thereof.
…utput, just to make sure I haven't missed anything around the edges.
This reverts commit 1c625a9.
CAVEAT: Sample classes originally were in the default (ie, no) package. I've taken the liberty of putting at least some of them under a package reflecting their intent -- general samples, xsltcservlet. There may be outdated references in the sample doc, or html, or jsp files which I haven't reconciled yet. Given how long it has been since anyone looked at these samples, that may not be an issue... but it should be reviewed, and arguably the samples should all be regression-tested (I doubt any of them are). |
…e old @xml.apache.org.
|
Content lists of all Maven build .jar and .war files confirmed as matching Ant equivalents, modulo java packages of samples, how version is handled, and the now-shaded (and newer) java_cup/runtime package. Todo:
|
…y easier to diff against ant builds.
…replicated inside the /samples/ directory, and the sample javadocs are now included in /docs/apidocs/. There's some other cruft (most of /docs/images/, /docs/xsltc/ design) which should be rewritten or discarded at some point. NOTE: We still need to update the docs (site and local) to reflect the Maven build, and its description of test is badly outdated.
|
Bin distro looks acceptable though not ideal. Deferred cleanup, should be added as Jira tasks:
|
|
I'm now getting a reasonable-looking xalan-java src tarball. I've confirmed that I can build from it. Rah! In the past, the src tarball/zipfile has included an embedded copy of xalan-test, for the convenience of anyone downloading source who wanted to confirm that their build had succeeded. (The binary distro did not include xalan-test.) Should the maven src distro:
(I'd rather not recreate the embedding of xalan-test's source, but it wouldn't be impossible, just ugly.) |
|
Reconciled with Master. |
|
Happy New Year. Have fun. Fix bugs. Support users. Clean code. Add features. Mostly in that order... ;-) |
For history of the previous version of this changeset, see #105. This branch's history was restructured, addressing some of the gripes expressed in that one.
Passing our core regression test suite: smoketest, apitest, and (with known non-regression issues) conf.xsltc. Deeper regression testing would not be a bad thing. I'd suggest particular focus on XSLTC, since we have changed the XPath tokenizer and grammar layers. There may also be other edge cases as a result of moving to current versions of libraries rather than the old ones we were carrying around in the Ant build.
Note that there are dependencies on where the serializer resources are located. If someone really thinks they need to be moved, I suggest opening a Jira ticket; there is no need to resolve that now.
This version has better handling for creating the build/ convenience directory (copy jarfiles to where the ant build put them) for compatibility with xalan-test.
This PR does NOT yet bring tests inboard. That will be dealt with when we mavenize xalan-test.
Note: I think I'm beginning to agree with the folks in the "squash considered harmful" camp. There was a specific reason for using it in previous environment I worked with, but not here. I'll bring that up for discussion on the mailinglist.