An overview of changes

 Rice 1.1 is now Rice 2.0 ◦ communicates the level of changes being made in the rice codebase

 all reusable unit testing components are in there own module (rice internal test tools) ◦ they are internal - don't use these! ◦ we don't want to make any guarantees about these APIs ◦ previously these classes were in the rice impl module and were used by client apps ◦ made unit testing frameworks dependencies of rice (which were automatically pushed on client apps) - htmlunit, junit, jetty ◦ polluted the main codebase with test code

 all of our existing tests are isolated in a place for integration tests - b/c that is what they mostly are ◦ located in a new test module ◦ using the failsafe plugin to execute unit tests ◦ some of this continues to change  ie. we might move these back to the modules under src/main/it after modularity work

 creating new real unit tests for each module ◦ runs fast, isolated (tries to only test the class being targeted) ◦ does not require spring, database, app server, etc.  trying to make it easier to unit test rice applications ◦ no more inline service locator calls ◦ more focus on DI - this is a tradeoff (slightly controversial and is a tradeoff)  kc is already doing this

 all libraries were updated to there latest version ◦ struts, spring, cxf, dwr, hibernate, ojb :-), commons libs, etc. ◦ possibly moving away from dead projects (xapool/jotm – peter?, oscache, displaytag) ◦ jee libs updated, minimum requirement is servlet 2.5 container

 each conceptual module of rice is broken up into multiple maven modules (jars, wars) ◦ kim, kew, ken, ksb, kcb, core, krad standalone, sampleapp, internal test tools, client contrib, development tools  standalone - the rice standalone server  sampleapp - the travel app  internal test tools - test code used across modules for unit/int testing  client contrib - code we are giving back to client apps  development tools - tools used during development/implementation of rice (encryption data loading)

web impl framwork api

 why do this? ◦ decrease the complexity of rice ◦ isolate external dependencies ◦ reduce coupling in rice ◦ allow module of rice to be developed and tested in isolation ◦ improve the quality of the rice codebase ◦ make it explicit what code client apps can use  which helps rice make guarantees on releases  helps client apps ensure they make is easier to upgrade versions of rice

 almost all package names in rice are changing  packaging by feature rather than tier  ex: all Parameter related things are in a single package but is split across multiple modules ◦ org.kuali.core.api.parameter, org.kuali.core.impl.parameter  this is hard and still a WIP

 delete dead code ◦ ten versions of key/value pair  delete redundant code, code we don't want to support ◦ utility classes (rice StringUtils) ◦ RIA ◦ deprecated code ◦ unit/int test code that we no longer use - we had a ton of redundant code here

 rice is focusing on code quality/while balancing "just get it done"  taking a code first approach to service apis but delivering WSDLs at release time  apis will be defined and documented! ◦ if I pass null to this service it does.... ◦ this DTO must have field x, y, z set

 apis are being tested with unit tests  immutable objects are now passed/returned from remote service APIs ◦ helps guarantee service contracts ◦ helps build thread-safe code  important for caching  helps us add to service apis in a compatible manner

 using nested "builders" for complex objects  what's the point? ◦ to allow a rice standalone server to be upgraded independently of client apps ◦ to make sure our APIs are built such that implementers can "easily" create there own implementations ◦ how do you do this now when behavior is not documented? ◦ how do you know that your custom implementation will continue to work? ◦ how do you implement complex methods like "lookup"?

 Standardizing the way to do lookups ◦ Richer api (not, and, or, in like, etc) ◦ No longer just a map ◦ A more well defined api which hopefully means easier to ensure vc & alternative impls  Standardizing the way we do caching ◦ Maybe Spring ehcache ◦ Still a research topic

 only used for BOs, EBOs, immutable service objects, unit tests  helps reduce the verbosity of certain parts of rice (ie. "just get it done")  groovy is maintained by SpringSource and has good integration with spring  awesome of unit testing especially when mocking objects, testing private methods  we are being very conservative with our use of Groovy  only using in certain code so that code could be reverted back to java if necessary

 adding dependencies ◦ Spring MVC (3.0) ◦ Tiles 2.x ◦ JQuery (core, ui, datatables ( fancybox ( validation(client side validation), jstree ( watermarking, growl messages)  removing displaytag, dwr?, struts from maintenance framework)  most changes are happening in maintenance, lookup, multivalue lookup, inquiry framework ◦ avoid overriding jsps, tag files, controllers

 deprecating transdoc framework  removing the requirement that rice only works with BOs - rice can work with any POJO  service backed, DB backed, etc.  supporting a richer api ◦ javascript is now a requirement, although still accessibility compliant ◦ can embed javascript in maintenance pages ◦ some html 5 support - still a research item ◦ support more html wiget types ◦ lightboxes, client-side validation, more validation types (cross field), must occur, etc.

 will require changes to DD files - but migration scripts should be possible  the requirements are being driven partially by the kuali student project  KC's holding page enhancement - may want to work with the krad team on this

 using Maven 3 ◦ may need to update Hudson/Jenkins to build with Maven 3  rice is delivering multiple libraries  clients should only depend on api & framework modules at compile time  please tell us if you need something that is currently in impl/web  supporting Tomcat 6 & 7 - with a minimum requirement on tomcat 6 (servlet 2.5) ◦ would encourage you to have a mixed environment with tomcat 6 & 7 to ensure compatibility  java 6

 some rice devs are using intellij due to issues with eclipse (mainly m2eclipse)