Package net.sf.farrago

Top-level package containing all Farrago subpackages.

Revision | $Id: //open/dev/farrago/src/net/sf/farrago/package.html#20 $
Copyright | Copyright (C) 2005-2009 The Eigenbase Project Copyright (C) 2005-2009 SQLstream, Inc. Copyright (C) 2005-2009 LucidEra, Inc.
Author | John V. Sichi

The UML diagram below illustrates the dependencies among Farrago subpackages:

Transitive depenencies are mostly left out (so if package A depends on package B, and package B depends on C, it's implied that package A may depend on package C as well). In this context, dependency means early binding; that is, the higher-level package references the lower-level package at compile time. Packages with italicized names are interface packages.

Note that the farrago.trace package is special in that it is allowed (and in fact required) to participate in circular dependencies with other packages.

TBD: dependencies on packages like java.sql, org.eigenbase, and MDR. Also need to show com.disruptivetech.**, com.lucidera.**. And:

- farrago.jdbc depends on farrago.release
- farrago.jdbc.client depends on farrago.fennel.tuple
- farrago.util depends on farrago.release
- farrago.runtime depends on farrago.jdbc.params

Dependencies are checked via the macker tool as part of Farrago checkin acceptance tests. Dependency definitions are in //open/dev/farrago/src/macker.xml.

Note that late binding is allowed to violate the layering. For example, the util layer defines the {@link net.sf.farrago.util.FarragoAllocation} interface. The db layer defines class {@link net.sf.farrago.db.FarragoDbStmtContext}, which implements FarragoAllocation, and passes an instance to {@link net.sf.farrago.util.FarragoCompoundAllocation}. When the FarragoCompoundAllocation is closed, it calls back via the interface, meaning at runtime, code in the util layer ends up calling code in the db layer.