You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@roller.apache.org by Dave <sn...@gmail.com> on 2007/01/25 16:31:54 UTC
Initial proposal for Roller 4.0 release
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.
Re: Initial proposal for Roller 4.0 release
Posted by Matt Raible <mr...@gmail.com>.
Looks good to me - especially since you guys are going to do all the work! ;-)
Matt
On 1/25/07, Dave <sn...@gmail.com> 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.
>
--
http://raibledesigns.com
Re: Initial proposal for Roller 4.0 release
Posted by Nelson Carpentier <ne...@gmail.com>.
+1
On 1/26/07, Anil Gangolli <an...@busybuddha.org> wrote:
>
> +1
>
> ----- Original Message -----
> From: "Dave" <sn...@gmail.com>
> To: <ro...@incubator.apache.org>
> Sent: Thursday, January 25, 2007 7:31 AM
> Subject: Initial proposal for Roller 4.0 release
>
>
> > 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.
> >
>
>
Re: Initial proposal for Roller 4.0 release
Posted by Anil Gangolli <an...@busybuddha.org>.
+1
----- Original Message -----
From: "Dave" <sn...@gmail.com>
To: <ro...@incubator.apache.org>
Sent: Thursday, January 25, 2007 7:31 AM
Subject: Initial proposal for Roller 4.0 release
> 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.
>
Re: Initial proposal for Roller 4.0 release
Posted by Craig L Russell <Cr...@Sun.COM>.
Hi Sean,
On Jan 26, 2007, at 10:51 AM, Sean Gilligan wrote:
>
>>> 2) I thought there was a wrapper for DB independence, so that
>>> Hibernate
>>> could still be fully supported?
>>
>> JPA is the wrapper as far as I understand.
> In the current version I recall there being a "Manager" interface
> that encapsulates the Hibernate API, and I thought the JPA work was
> another implementation of that interface. Am I wrong?
>>
>> Hibernate implements JPA, other things implement JPA.
> Roller won't require any "vendor-specific" extensions to the JPA?
> I've been reading "Java Persistence with Hibernate" and the authors
> imply that to do anything "real" you'll need extensions to JPA
This is a classic vendor response to a standard API. Unless you
continue to use Hibernate you won't be able to deploy your "real
application".
Posh.
Craig
> whether you use Hibernate or not.
>
> -- Sean
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: Initial proposal for Roller 4.0 release
Posted by Mitesh Meswani <Mi...@Sun.COM>.
Sean Gilligan wrote:
>
>>> 2) I thought there was a wrapper for DB independence, so that Hibernate
>>> could still be fully supported?
>>
>> JPA is the wrapper as far as I understand.
> In the current version I recall there being a "Manager" interface that
> encapsulates the Hibernate API, and I thought the JPA work was another
> implementation of that interface. Am I wrong?
Thats correct. JPA implementation of roller is another implementation of
the "*Manager" interfaces.
>>
>> Hibernate implements JPA, other things implement JPA.
> Roller won't require any "vendor-specific" extensions to the JPA?
> I've been reading "Java Persistence with Hibernate" and the authors
> imply that to do anything "real" you'll need extensions to JPA whether
> you use Hibernate or not.
Thats not entirely true. For example we were able to implement all of
roller backend functionality without requiring any vendor specific
extension :)
-Mitesh
>
> -- Sean
Re: Initial proposal for Roller 4.0 release
Posted by Sean Gilligan <se...@msgilligan.com>.
>> 2) I thought there was a wrapper for DB independence, so that Hibernate
>> could still be fully supported?
>
> JPA is the wrapper as far as I understand.
In the current version I recall there being a "Manager" interface that
encapsulates the Hibernate API, and I thought the JPA work was another
implementation of that interface. Am I wrong?
>
> Hibernate implements JPA, other things implement JPA.
Roller won't require any "vendor-specific" extensions to the JPA? I've
been reading "Java Persistence with Hibernate" and the authors imply
that to do anything "real" you'll need extensions to JPA whether you use
Hibernate or not.
-- Sean
Re: Initial proposal for Roller 4.0 release
Posted by Henri Yandell <fl...@gmail.com>.
On 1/25/07, Sean Gilligan <se...@msgilligan.com> wrote:
> I've been a little out of the loop on the DB work, but the 4.0 proposal
> seems to be putting too much distance between Roller and Hibernate.
>
> Three questions:
>
> 1) Other than the LGPL license preventing bundling on ASF are there any
> technical issues with Hibernate?
Just that one.
> 2) I thought there was a wrapper for DB independence, so that Hibernate
> could still be fully supported?
JPA is the wrapper as far as I understand.
Hibernate implements JPA, other things implement JPA.
> 3) If #2 is true, then are you just saying that you aren't going to
> maintain Hibernate anymore?
I imagine it'd be like a Postgres bug. If someone has a Hibernate
problem, then it's a question of trying to replicate it in that
environment rather than it being the standard environment.
Hen
Re: Initial proposal for Roller 4.0 release
Posted by Sean Gilligan <se...@msgilligan.com>.
I've been a little out of the loop on the DB work, but the 4.0 proposal
seems to be putting too much distance between Roller and Hibernate.
Three questions:
1) Other than the LGPL license preventing bundling on ASF are there any
technical issues with Hibernate?
2) I thought there was a wrapper for DB independence, so that Hibernate
could still be fully supported?
3) If #2 is true, then are you just saying that you aren't going to
maintain Hibernate anymore?
Thanks,
Sean
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.
>
>
Re: Initial proposal for Roller 4.0 release
Posted by Allen Gilliland <al...@sun.com>.
+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.
Re: Initial proposal for Roller 4.0 release
Posted by RW <ro...@tauceti.net>.
Hi,
there is one thing I always was not very satisfied with is searching
with roller.
Lucene is definitly a fine search engine but what I'm really missing is
the search
for compound words and stems. For example when I search for "monkey" I will
not get entries like "greasemonkey". Or a search for "house" would not
get me
entries like "household". Some weeks ago I've read in a java magazine
(german) that Lucene is able to handle stems and compound words.
Since I'm using PostgreSQL I've created a fulltext index with Tsearch2
(http://www.sai.msu.su/%7Emegera/postgres/gist/tsearch/V2/) and
the Snowball stemmers (http://www.snowball.tartarus.org) which works very
well. But of cource it would be much better to have it in the Roller
code itself.
I would try to implement it by myself but I think my knowledge about Java
coding isn't sufficient and I've absolutely no experience with Lucene
and the
Roller code. So this would take years I think ;-)
Greetings
Robert
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.