Maven 2 Migration

Purpose

This page is to document the migration of uPortal 3 to Maven Two.

Project Design

Code Module List

See the current list of Code Modules here, and the rationale for their creation. Later the Code Modules page might be expanded to include the dependency graphs.

The following tree structure is a first pass at a project/sub-project re-design for uPortal 3

EAR - Desribes an EAR that will reference other portlets that should be deployed with the uPortal WAR. Will also include shared configuration such as JNDI data source configuration.
- WAR - Describes the WebApp for uP3, would likely have all the JSPs for the framework portlets, the bean contexts for the portlets and the portal and logging configuration.
  - API - As code is moved into other modules; tools, portlets, mock. APIs depended on will be moved to this project, it should contain mainly interfaces.
  - Implementation - Everything else. All framework code that doesn't fit into one of the other sub-projects
  - Mock - All of the mock objects for testing.
  - Tools - Base for tools such as DbLoader and Deployer.
    - DbLoader
    - Deployer
  - Framework Portlets - Base for framework portlets.
    - Cache Manager
    - Channel Adapter
    - Error
    - Locale Selector
    - Login
    - Portlet Manager
    - Password Manager
    - Permissions Manage
    - Subscription
    - Groups Manager

Proposal

I'll offer up the following proposal for ultimately moving UP3 to Maven 2, flames comments requested!

Identify portions of the up3 codebase for re-factoring

Using whatever means available (I'm using classycle for example), identify candidates in the up3 codebase for refactoring, and refactor them where it makes sense.

First, I think we need to specifically focus refactoring efforts on classes that have dependencies on implementations instead of interfaces. This might mean creating a new interface where one didn't exist previously, or modifying existing interfaces. It might mean creating utility classes, object factories, or using Spring to obtain a concrete class. I don't know, it will probably be different on a case-by-case basis.

If we can get most of the codebase using interfaces, that will make it easier to organize the code into Maven 2 sub-projects because the dependency graphs will be less complex.

We can decide if the refactoring effort should use Jira or not. I would suggest that it should. Using the CacheKeyImpl example above, I would create a single issue in Jira that would encapsulate the refactoring work surrounding CacheKeyImpl.

Create dependency graphs

Use tools to create dependency graphs of the refactored codebase. This can be done in an ongoing, continuous way as the refactoring proceeds.

Define the M2 project structure

Hash this out on the wiki or jasig-dev list. Questions like: what makes a framework portlet different from a non-framework portlet could be answered at this phase of the project, if the answers aren't already obvious from the refactoring work and dependency graphs.

At this juncture it would probably be helpful to have a codebase that we could move around at will without worrying about hosing trunk. Perhaps a branch where we can test out different structures and builds?

Relationship of Ant and Maven

I'm not sure that a goal of this work is to allow the ant-based build to run in parallel with the maven 2 build. However, there is a Maven 2 ant mojo, which could allow us to re-use all or some of the existing build.xml. I think this is a key discussion point - what will happen to the ant-based build.

Archived Portal Exploration