uPortal3 Community Goals and Objectives

Purpose

This document seeks to capture community goals and high level objectives for the Winter 2007 uPortal3.0 GA release.

Introduction

Discussions during the 2007 JASIG Summer Conference in Denver have indicated community consensus around a common path forward regarding the much anticipated uPortal3 release. This has also been discussed on the uPortal developer email list and on the uPortal deployer email list. This common path forward leverages the best of current production uPortal release, uPortal2, and incorporates code and proven designs from the uPortal3 sandbox. The ultimate goal is a uPortal3 GA release ready for production deployment by Winter 2007 that meets the community goals for a next generation Enterprise Portal Platform and leverages the best of uPortal2.

uPortal3 Community Goals

• Platform for evolution & innovation based on a modern software architecture
• Leverage as much as possible production tested, scalable, award winning, rock solid uPortal 2 code base
• Encourage the uPortal community to move together by minimizing upgrade pain while still meeting our goals
• Feature parity with current production uPortal release, uPortal2
• Improved User Experience
• Improved Accessibility support
• First Class Portlet Support

Tier One Technical Deliverables (Required for uP3.0 GA Winter 2007)

Tier One technical deliverables define the minimum objectives required for a uP3.0GA release. This release must satisfy the community goals while providing an evolutionary path for Tier Two deliverables that is consistent with the uPortal Release Strategy. Tier One objectives must be completed for the Winter 2007 uPortal3 release.

1.0 Maven2 Build Process

Key to long term health and sustainability is a build process that is easy to use, encourages modularity and streamlines the release process. Building on the success of Maven2 for uPortal3 sandbox and CAS3, uPortal will adopt Maven2 and refactor the source code organization to facilitate loose-coupling between packages, better code modularity and testing.

1.1 Spring Framework

The Spring Framework provides the basis for a modern flexible software architecture for uPortal3. Building on the adoption of Spring by components such as PersonDirectory and GAP, and the uPortal3 sandbox, Spring will be elevated to be the unifying framework for uPortal components and services. This modern architecture will increase the testability and quality of components, and lead to overall less uPortal specific plumbing code.

1.2 Code Cleanup

Over time projects tend to accumulate cruft in the form of source code that is deprecated, obsolete, or abandoned. Eventually, this make ongoing maintenance and evolution more difficult that it should be. A major release is a good time to prune the garden and remove unnecessary code from the repository.

1.2.1 Remove Deprecated Code

Before removing deprecated code that is a published or assumed public API, the community must be consulted with regards to the amount of pain introduced in the upgrade path. Consideration must be given to the goal of minimizing upgrade pain while balancing the long term goals of the project. Code that is internal implementation can simply be removed or refactored.

1.2.2 Externalize PersonDirectory and GAP

PersonDirectory and GAP have already been elevated to JASIG projects in their own right. Migrating to these reduces code duplication between the projects and improves modularity.

1.2.3 Replace RDBMServices and LDAPServices with Spring Equivalents

Replacing the current implementations with Spring Equivalents further reduces the maintenance burden while moving to a modern software architecture.

1.3 Pluto 1.1

Pluto 1.1 is the current actively maintained reference implementation of the Portlet specification. Pluto 1.1 will enable uPortal to provide 1st class support for Portlets, provide a modern architecture, and an evolutionary path towards JSR-268 support.

Tier Two Technical Deliverables (Nice to haves for uP3.0 GA Winter 2007, but could come later, i.e. 3.1, 3.2,...)

Tier Two technical deliverables have been identified as objectives consistent with community goals for a next generation Enterprise Portal Framework, uPortal3. Tier Two deliverables may be completed for the Winter 2007 uPortal3 GA release as time and resources allow. Objectives not completed by uPortal3.0 release could be implemented in subsequent release consistent with the uPortal Release Strategy.

2.0 Deprecate/Remove or find a maintainer for ALM

Community consensus is that DLM is the Layout Manager for uPortal now and into the future. Without a strong advocate and maintainer for ALM, over time adopters of ALM are at increasing risk of lack of support and evolution. The community seeks the best path forward to send a strong signal to current and potential uPortal adopters that DLM is the Layout Manager they should be using.

2.1 Adopt a Security Framework - ACEGI & CAS

ACEGI (aka Spring Security) & CAS provide a best of breed security framework for any web based application, including uPortal. Removing uPortal specific security code further reduces the maintenance burden and makes it easy to integrate with local Identity Management infrastructure.

2.2 Post uP2.6 DLM Enhancements

DLM enhancements that are consistent with the goals of improvement the User Experience and Accessibility should be consider for uPortal 3 GA.

2.3 Migration Tools & Guides

The overriding community goal is to make migration to uPortal3 as easy as possible. However this is at times at odds with other goals of providing a next generation platform. Whenever necessary migration tools should help easy the burden and documentation should be available to help and encourage current adopters to upgrade.

2.4 Mature out of the box functionality

There are a number of open source components developed for and commonly used with uPortal that do not currently ship with uPortal. This results in expenditure of deployer effort per-deployment to find and tame these plugins, and version mismatch thrash (what version of what announcements channel will work with what uPortal?) Where appropriate common external modules should be drawn into the uPortal project proper, maintained with uPortal, in order to make uPortal a more compelling platform and one on which it is easier to deliver a better portal faster. Andrew Petro pitched value of this approach was pitched at the uPortal developer meeting at JHU and at the Denver JA-SIG conference.

Branch Management

Post uPortal2.6 GA, the trunk will be managed towards the future uPortal3.0 release. Significant or sweeping changes should first be implemented on an experimental branch of the trunk. Once working they can be merged back into the trunk. The goal is to always have a working version on the trunk.

Project Team

Many of the objectives for uPortal3 require significant and sometimes sweeping changes to the code base. In order to maintain quality, and leverage the best of talent of the community, there must be open and visible dialogue on the uPortal dev list concerning possible design and implementation choices. Only after consensus is reached should any major work be implemented and committed.