Details
-
Type:
Task
-
Status:
Closed
-
Priority:
Blocker
-
Resolution: Fixed
-
Affects Version/s: None
-
Fix Version/s: 1.0
-
Component/s: Development, Documentation, Quality Assurance
-
Labels:None
-
Similar issues:
KULRICE-1923Packaged standalone server war file does not include a web.xml KULRICE-2764Deploy Rice standalone server to our test environments KULRICE-2816Deploy Rice standalone server with Recipe sample app to test environments KULRICE-4868Create war module for our standalone server KULRICE-3031Default version of maven war plugin fails with a null pointer exception on maven 2.0.10 KULRICE-3525The jsp jar is currently being included in the Rice war KULRICE-1348Some jars are getting included in the standalone war that shouldn't be included KULRICE-6781Test standalone server install instructions KULRICE-4795Create sample travel app that uses war overlays and embedded mode KULRICE-10632Test env for client app using standalone -
Rice Team:QA
-
Rice Module:Rice Core
Description
We need to verify that the standalone war that is generated out of the "web" module still works properly. What we should do is get the deployment of it to test environments set up again (via the "dist" ant target and the deployment scripts on wsa123).
Issue Links
- discovered
-
KULRICE-2855
Document Kuali Rice Standalone Server installation and configuration
-
- is relied upon by
-
KULRICE-2764
Deploy Rice standalone server to our test environments
-
-
KULRICE-2649
Verify that our jsps and tag libraries are using quotes properly and work successfully in Tomcat 5.5.27
-
Activity
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.
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?