1. Cedar Solutions Software
  2. GWT
  3. cedar-common

Wiki

Clone wiki

cedar-common / Home

Common Java Utilities with Support for GWT 2 and AppEngine

CedarCommon is a library of general Java utility code. Separate jars also include utilities developed for use with Google Web Toolkit (GWT) and Google AppEngine (GAE) using the Mvp4g model-view-presenter framework. CedarCommon was originally developed along with the Santa Exchange GWT demonstration project. The project was originally maintained at Google Code, but moved here to BitBucket when Google announced retirement of the Google Code service.

Available Documentation

See the Table of Contents at the bottom of this page for a list of other wiki pages related to CedarCommon.

Which GWT Version?

The current version of CedarCommon is designed for use with GWT v2.7. If you need support for GWT v2.5 or v2.6, use CedarCommon v4.12.1. There is very little functional difference between CedarCommon v4.12.1 and early versions of v5.x, other than support for GWT v2.7.

Note: GWT 3 is substantially different from GWT 2, and the interface is not backwards compatible. At this time, there are no plans to officially support GWT 3 in CedarCommon.

Using CedarCommon

The easiest way to use CedarCommon is via Maven or a Maven-enabled tool like Gradle. Signed CedarCommon jars are available in Maven Central using group id com.googlecode.cedar-common.

There are six different packages:

Package Code Javadoc Maven Description
cedar-common-util Code Javadoc Maven General utility code
cedar-common-gwt Code Javadoc Maven Utility code for use with GWT 2 and Mvp4g
cedar-common-gae Code Javadoc Maven Utility code for use with GWT 2 on Google AppEngine
cedar-common-testutil Code Javadoc Maven Utility code for use with junit, such as assertions and test setup
cedar-common-gwttestutil Code Javadoc Maven Utility code for use in testing GWT 2, including a stubbed test runner
cedar-common-gaetestutil Code Javadoc Maven Utility code for use in testing GWT 2 applications on AppEngine

The packages are broken up so that it's possible to use the the general utilities without pulling along any GWT or AppEngine dependencies, and so it's possible to use the GWT functionality without pulling along any AppEngine dependencies. The AppEngine features are designed to be used with GWT and do not stand alone.

Revision Control

There are several different Mercurial repositories related to CedarCommon, each hosted on on BitBucket.

Project Mercurial URL Description
CedarCommon https://bitbucket.org/cedarsolutions/cedar-common Java source code for all Maven components
CedarBuild https://bitbucket.org/cedarsolutions/cedar-build Gradle plugins used to standardize the build process

Continuous Integration

Continuous integration via Jenkins is graciously hosted by CloudBees using their DEV@Cloud solution.

alt text

Dependency Notes

All CedarCommon code is designed to be used with Java 6 and sets a Java 6 source and target compatibility level. However, recent versions of the AppEngine runtime only work with Java 7. So, although you can use CedarCommon functionality with Java 6, you'll need a Java 7 JDK to build or test the code.

The GAE-related CedarCommon packages do include Maven dependencies on AppEngine jars. However, I recommend that you exclude these dependencies in your application and manage them independently. This way, you can use a newer version than CedarCommon. I typically don't release a new version of CedarCommon just to bump the GAE version. For an example of how to do this with Gradle, see the SantaExchange build.gradle file, in the dependencies section.

Build System

The SantaExchange and CedarCommon code is managed using the Gradle 2 build system. Underneath, dependencies are managed using Maven, mostly from Maven Central.

When I originally wrote SantaExchange, I checked dependency jars into revision control, because this is what the Google Plugin for Eclipse encourages you to do. This was less than ideal: the Mercurial repository eventually grew very large due to the frequent AppEngine upgrade cycle. Upgrades in general were painful, and I also had to manually track the source and version of each jar, etc. in my own documentation.

Using Gradle has simplified the whole process, even if it does add an extra setup step for anyone who wants to work with the code. There are notes in the wiki under DevelopmentEnvironment and SourceCode that will walk you through the process.

Table of Contents

Technicalities

Procedures

References

Updated