Hi, On 7/16/07, Ate Douma <[EMAIL PROTECTED]> wrote:
- design and implement a new decorator model and api to allow much easier and cleaner definition of layout and portlet decorations
I'm interested in this feature, I'll be happy to help either coding or providing end user feedback. Independently of the underlying framework I'd like this new API to be a good foundation to build a wysiwyg layout and portlet decoration portlet. It's not clear to me how this new API should be, but I think I could help to implement it if the goals and design are documented somewhere.
- possibly a JCR based portal registry and page/site management
I'm currently working in a few jcr powered cms portlets which integrate the contents to the underlying portal's site, see http://code.google.com/p/jcr-portlets/. I've also implemented a jcr based page manager, its design is not aligned to what David Sean Taylor had in mind but since I gained some experience with the PageManager API while implementing it I guess I'll be able to help giving end user feedback and providing patches for the new implementation. br, edgar
- better support for and possible even out-of-the-box integration with Geronimo/Glassfish/Jetty/JBoss/Websphere/WebLogic - Jetspeed "light" (no need for database persistence and much simplified page/site management) I invite everyone to comment, vote, and propose other critical features you are "dying" for *and* are willing to invest time and energy in bringing it about. Note: none of this "list" is fixed or definitive, its just my (and some others) initial feature list. But also note: in line with our Apache development model, *only* those features people are really willing and able to invest time and energy in (discussing, designing, coding, reviewing, testing, commenting, etc.) can and will be realized. Some of the above possible features are going to effect our current API, component model and our build setup. To protect our current users, I've created a new branch JETSPEED-2.1.3, for continued support and bug fixing based on the 2.1.2 release. This allow us to start working in the trunk with possibly some hefty changes, refactoring etc. needed for changes like I described above. And in anticipation of our probable move to a maven-2 build environment, I bumped the trunk development version to 2.2-SNAPSHOT. For us committers, this has a major consequence: *any* change committed to the JETSPEED-2.1.3 branch or trunk needs to be reviewed if it is valid and/or required for inclusion in the other svn tree (trunk or branch) as well. If so, it needs to be committed twice, possibly even refactored for that purpose! Now, as far as I'm concerned, we should not introduce new features or big enhancements in the JETSPEED-2.1.3 branch anymore but reserve those for trunk only. If large scale development would commence in the branch, we will endanger the 2.2-SNAPSHOT trunk development big time. To be able to reach a new Jetspeed 2.2 release ASAP, trunk development needs to be our first and highest priority. Apache is all about community based development, and I'm inviting all of you to actively participate and help us out with questions, proposals, patches, test reports or any other contribution as much as you can. Let's all work together to make Jetspeed 2.2 the best Open Source Enterprise Portal so far. Regards, Ate --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
