Clone wiki

cedar-common / Home

Note: As of June 2018, this code is only lightly maintained. It was originally written starting in 2011, which is an eternity ago in user-interface terms. Today, GWT is basically dead as a user interface development framework, making this code mostly irrelevant. Besides that, the Santa Exchange backend no longer works with the most recent Java 8 API for Google AppEngine, so as of January 2019, there won't even be any infrastructure on which it will run. I don't have the time or the motivation to fix it, so the GWT- and AppEngine-focused portions of this code don't really have a purpose any more.

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

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 Java source code for all Maven components
CedarBuild Gradle plugins used to standardize the build process

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