The "dist" target is called in the rice build.xml during the build process that generates the war which is currently being deployed to wsa131. There is a POM in the web module that is apparently designed to produce a war with a subset of libraries and configuration files...

Which of these are you referring to? If it's the former, and you want the test instance on that application server tested, how would I go about getting an idea of what functionality is under test. Do we have test matrices left over from prior releases?

This tasks is essentially just the tast to get our standalone war packaged and tested to make sure it deploys properly. That's been done so this issue can be resolved.

The standalone war does not deploy successfully because project files that have to do with the build are tightly coupled to the hosting environment.

More specifically, the web module POM excludes certain libraries from the final packaged war that are necessary for the running of the standalone server, unless the standalone war is deployed to wsa131.

My proposed short-term solution will involve the creating of a profile in Maven which will be activated when the 'ant dist' target is called by the bash script 'do-daily-update.sh'

Casey, the build is kind of set up this way already (I think we discussed this last week some). You can pass the excludes.jta property to the build and it will create a packaged war without JTA libraries in it, but the default build now includes them. In light of that, is there any reason to continue pursuing a maven profile solution here?

There is no reason to devote any more time to accommodating the wsa131 environment. I made the comment regarding profiles prior to your checking in of the jta fix to the build.xml file.

Ok, great, i'll mark this one as resolved then. Thanks.

Bulk change of all Rice 1.0 issues to closed after public release.