Rice 2.0An overview of changes

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

the rice codebase

Version change

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

unit/integration testing

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

unit/integration testing

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

unit/integration testing

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

libraries

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)

modularity

modularity

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

modularity

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

modularity

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

codebase cleanup

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

version compatibility

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

version compatibility

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"?

version compatibility

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

version compatibility

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

Groovy

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

KRAD

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.

KRAD

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

KRAD

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

For the CMs

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

Intellij