+1, with a couple comments/conditions.
1. That we use the current code in the trunk to make a 3.2 release
first, which hasn't officially been proposed yet because 3.1 hasn't gone
out. Then this 4.0 release follows after that.
2. That 4.0 isn't limited to just these things. April/May is quite a
ways away and the code for the 3.2 release can probably be considered
close to complete, so I want to make sure this proposal is open to other
code additions. i.e. the reorganization of the Roller Weblogger code
based on some of our "modular Roller" discussions.
assuming those 2 things then I think this sounds good.
-- Allen
Dave wrote:
I'd like to propose a Roller 4.0 release to introduce some
infrastructure changes that we've been discussing and waiting for. The
proposal might be somewhat controversial so I'd really like to hear
from as wide a spectrum of the Roller community as possible. If we can
find consensus, I'd like to create a roller_4.0 branch and start
working on this as soon as possible. I think we can target an April or
May 2007 release.
Here's the proposal page on the new wiki:
http://cwiki.apache.org/confluence/display/ROLLER/Proposal+Roller+4.0+Release
Here's the current full text of the proposal:
Abstract
This is a proposal to make a Roller 4.0 release, a major new release
to introduce some infrastructure improvements and upgrades that we've
been wanting to make for a long time. This includes a new data-mappper
back-end with a JPA implementation, Struts 2 support and a requirement
for Java SE 5.
Requirements
There are four requirements: add JPA back-end, remove Hibernate-native
back-end, upgrade Struts and require Java SE 5. Here are the details:
* Introduce data-mapper based back-end with JPA implementation.
Introduce a new back-end implementation based on the data mapper
architecture, which is designed to support multiple back-end
implementations, and a new Java Persistence Architecture (JPA)
implementation of those interfaces. The JPA back-end already exists
and is passing 100% of our JUnit "business" tests.
* Remove Hibernate-native back-end. Now that we have a JPA based
back-end, we can drop our Hibernate-native support thereby removing
any dependence on LGPL from Roller code. If folks want to continue
using Hibernate, they can either stick with Roller 3.0 or use
Hibernate's JPA API support.
* Upgrade to Struts 2. The Roller UI needs significant improvement
and modernization. It's clunky in places and does not meet the higher
standards that are expected of "Web 2.0" web applications. But we
don't want to do additional UI work with Struts 1.x. We're tired of
the Struts 1.x pain and those of us who have looked at Struts 2
believe it's very good upgrade and are ready to make the move. We can
add Struts 2 support to Roller, keep our existing Struts 1.x code in
place and migrate portions of the UI as needed (this proposal does not
yet include any UI rewrites, just the addition of Struts 2). Upgrading
to Struts 2 does not preclude use of JSF in Roller because it's
possible to use JSF pages and components in a Struts 2 application.
* Introduce requirement for Java SE 5. We've been stuck on Java
1.4.2 for a long time now, there are significant improvements in Java
SE 5 and the libraries that we depend on are starting to take
advantage of those improvements (i.e. Struts annotations and ROME)
Issues
Issues to be considered
* Which JPA implementation should we ship with Roller 4.0? We've
been doing all of our worth with the Glassfish/Toplink implementation,
so that's probably the best choice.
Design
Not much design work to do. We simply promote the JPA back-end from
the sandbox, add Struts 2 to the mix, change the build script to
require Java SE 5 for release build and test like crazy.
