1. An overview of changes

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

3.  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

4.  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

5.  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

6.  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

7.  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)

8. web impl framwork api

9.  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

10.  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

11.  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

12.  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

13.  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

14.  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"?

15.  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 3.1 + ehcache ◦ Still a research topic

16.  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

17.  adding dependencies ◦ Spring MVC (3.0) ◦ Tiles 2.x ◦ JQuery (core, ui, datatables (http://www.datatables.net/), fancybox (http://fancybox.net/), validation(client side validation), jstree (http://www.jstree.com/), 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

18.  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.

19.  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

20.  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

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