Spinning off GAP

Owned by Dan Ellentuck
Last updated: Jun 17, 2005Version comment
2 min read

Rationale

  • remove extraneous stuff from the uPortal codebase.
  • let other applications like HyperContent use the groups and permissions APIs.

The Project Plan

The project has been divided into 4 components:

  1. Common - the underlying service layer
  2. Groups Core - the groups types and the composite group service
  3. Group Services - the individual group service components, e.g., local, PAGS, etc.
  4. Permissions - the authorization service

See the JIRA issue tracker for Groups and Permissions for a description of the tasks for each component.

Collaboration with related Projects

Grouper
Sakai

Notes

The plan is to start by creating a common service layer, wired together using Spring, with the individual services available as Spring-managed beans. Next publish the public Groups and Permissions api's, so uPortal 3 developers have something to write to. Then we can move on to migrating the services themselves. Finally, we could back-port the GAP code to uPortal 2.6, where it could be available as an optional configuration. The advantage would be that you could use Spring to do service configuration and have be able to plug in external implementations of common services.

Keith Stacks is currently working on some enhancements to PAGS and the permissions framework. These will probably have to be applied to both the MAIN and the independent GAP code.

When the spun-off GAP becomes available, we can decide if we want to rip out the code that remains in the uPortal packages or continue with an integrated GAP in uPortal 2.x.

The code seems to divide into the following areas, ultimately corresponding to individual jars:

  • gap-common
  • gap-groups-core
  • gap-groups-services
  • gap-permissions