Pluto-Jetspeed coordination - [Fwd: Further Jetspeed-2 development plans]

[Ate Douma <at...@douma.nu>]

Dear fellow Portals community members,

At the Jetspeed-2 project we've started a discussion about some big scale development plans for the next release 2.2.
As I think several items of the feature list I proposed might be of high interest to the Pluto community and its committers as well, I'm forwarding the initial 
message I send out to the jetspeed-dev list a few days ago.

For those interested but not subscribed to the jetspeed-dev list, here is a link to the thread in Nabble:

   http://www.nabble.com/Further-Jetspeed-2-development-plans-tf4087420.html

Besides the highly important targets of bringing Jetspeed 2.2 in sync and up to date with Pluto 1.1.x (or even 1.2.x), I also proposed a cleaner and lightweight 
implementation of our component architecture to allow assembling a Jetspeed "light" portal.

The discussion which took place first here and then continued on general@portals.apache.org about hot deploy / auto assembly design for Pluto Portal was one of 
the reasons for me to bring up this specific proposal.

In the past (already almost 2 years ago) we had a similar discussion but that never took off.
But I do belief there can be much benefit for both the Pluto and Jetspeed community and our whole Portals community to consider this again.

Of course, it will take us (at Jetspeed) some time to first get in sync with the current Pluto container again, and before that we are going to need to write a 
complete new build environment. But I'd very much like to take up this proposal if there is enough interest in both our communities to work together on a 
solution which provides reusable, and possible separated out, components which can be used by both our portals.
If this works out well, we should be able to deliver a trimmed down, light weight Jetspeed engine together as a joined effort from the whole Portals team.
And this engine could then also be used at the core of, or as a replacement for, the increasingly higher demands on Pluto Portal.

I think it would be great if we can "tear down" our virtual sub project borders and see all our team members work together on both Pluto and Jetspeed (and 
Bridges) as just different end products from a single project team.

Right, I know this might be a bit too optimistic and day-dream kind of rambling, but I'm actually quite serious and like to invite all Pluto team members and 
its users to join our discussion about the Jetspeed-2 development plans. Its currently held at the jetspeed-dev list, but can be moved (partly) just as well to 
general@ when that's more appropriate.
I'm very much looking forward to feedback on this and it would be great if we can (in hopefully a few months time) really start working together.

Best regards,

Ate

p.s. I'm leaving on a 3 weeks holiday the day after tomorrow, so I myself won't be able to respond after that until Aug. 9 again :)


-------- Original Message --------
Subject: Further Jetspeed-2 development plans
Date: Mon, 16 Jul 2007 17:05:47 +0200
From: Ate Douma <at...@douma.nu>
Reply-To: Jetspeed Developers List <je...@portals.apache.org>
To: Jetspeed Developers List <je...@portals.apache.org>

Dear community,

With finally the release for Jetspeed-2.1.2 behind us, the time has come to think of and start some large scale enhancements and changes.

Some of the biggest improvements and features on my wish list, and for which I already know others have interest in too, are:
- moving from our maven-1 and maven-2 hybrid build environment to *one*, clean maven-2 build environment
- align with the latest Pluto 1.1.x container (and possibly even the near 1.2.x version)
- start working on full JSR-286 Portlet API 2.0 support (which requires aligning with at least the Pluto 1.2.x version)
- review and redesign our portal security model and implementation
- multiple authentication/authorization schemas to support truly separated access & maintenance of "communities" in one portal
- review and redesign our portlet preferences model and implementation (Java preferences)
- design and implement a new decorator model and api to allow much easier and cleaner definition of layout and portlet decorations
- possibly a JCR based portal registry and page/site management
- 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: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org