1 / 21

Rice 2.0

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)

maxim
Télécharger la présentation

Rice 2.0

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Rice 2.0 An overview of changes

  2. Version change • Rice 1.1 is now Rice 2.0 • communicates the level of changes being made in the rice codebase

  3. unit/integration testing • 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. 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

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

  6. libraries • 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) • jeelibs updated, minimum requirement is servlet 2.5 container

  7. modularity • 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. modularity api framwork impl web

  9. modularity • 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. 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

  11. codebase cleanup • 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. version compatibility • 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. 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

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

  15. 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

  16. Groovy • 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. KRAD • 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. 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.

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

  20. For the CMs • 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. Intellij • some rice devs are using intellij due to issues with eclipse (mainly m2eclipse)

More Related