rice 2.0
DESCRIPTION
Rice 2.0. An overview of changes. Version change. Rice 1.1 is now Rice 2.0 communicates the level of changes being made in the rice codebase. unit/integration testing. all reusable unit testing components are in there own module (rice internal test tools) - PowerPoint PPT PresentationTRANSCRIPT
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