Edgar, David,
First of all, both thanks a lot for your input and offer to join in.
I've included both your responses and added some additional comments inline
further below.
I'd like to propose we start discussing and designing possible solutions before
hacking away at the code.
Some of these features potentially are going to have big impact throughout the code base (like moving to JPA as David proposed), and I think for those type of
changes we need full support from everyone involved and a clear planning who is going to do what, when and with which intended result.
Probably the biggest step to take though is rewriting our current build
environment to a new and clean maven-2 only based setup.
Already more than a year ago, David also brought this up but at that time we
were not ready yet for several reasons.
I really think now is the time though to do this and also that we should do it
now before starting anything else.
Earlier this year I started out trying to create a new m2 build environment in
the J2-M2-REDUX branch based on the 2.1 release.
Because of lack of time, I haven't been able to complete my mission to build a complete portal, provide separate assemblies for different custom configurations
and setups, and a migration path for our large (and often paying customers) community which still run maven-1 based custom portal projects.
I started from scratch, throwing out everything from our current build
environment, and building it up again bit by bit.
I have no real intention to go back to that branch though now. The current code base already is too far ahead of the base line for that branch to even consider
merging it back in.
But I invite anyone interested to look at what I've done there so far and review if its feasible to redo it and expand on as the bases for our new maven-2 only
build environment in the trunk.
Which brings me back to a comment I made above.
I will send out a separate email to this list describing my intended solution for the J2-M2-REDUX branch, the problems I encountered as well as how I tried to
solve them. This maybe can use as starting point for properly discussing how to provide a proper m2 build environment.
Repeating and continuing the solution I started, or going at it a completely different way, I don't mind. As long as we end up with a feasible solution which
covers important goals like a migration path for our current m1 and m2 users.
So, I propose we proceed with discussing and designing this major step on the
list first, and do the same for the other big features/changes we would like to
do.
This way, our whole community will be able to chime in and join the effort if
they are interested and we'll be much better ensured we're on the right track.
I initially thought maybe we should use the Wiki for this. But my feeling is that the Wiki is great for providing and linking information bits, but less so for
discussion and design tasks. Yet, if anyone feels better at using the Wiki (too), by all means, go ahead.
I also propose we follow 2 simple guidelines for our list based design
discussions:
- use a subject clearly indicating which feature is under discussion, like: [M2 build
design] <optional sub topic>
- keep the design thread on topic: don't hijack a thread for a different/new
subject, open a new thread if needed instead
Tomorrow evening I'll try to kick start the [M2 build design] thread, but if
someone has a dying need to beat me to it, be my guest ;)
Regards,
Ate
p.s. I'll be away for a 3 week summer holiday starting this Saturday. So although I'd like to help kick start the [M2 build design], I'll be 100% offline from
Saturday until Aug. 9th. Would be great to come back and see a lot has happened already by then ;)
Further comments inline below:
Edgar Poce wrote:
> 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.
+1
Although my initial target is simplifying and improving our current decorator templates and scripts first, being able to define and edit them through a
(wysiwyg) portlet definitely would be the ultimate goal indeed.
> 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.
Well, I haven't thought this through myself either, I just know our current
situation is too complicated and elaborate.
You're welcome to come up with an initial proposal or join in later after I've
found the time to do so (or someone else).
This feature is not the highest on my list, but close.
>
>> - 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.
+1 again.
Content management and proper integration in the portal *is* part of my top
items.
Again feel free to initiate a proposal already, I will definitely participate
in this.
>
> br,
> edgar
-------------------
David Jencks wrote:
On Jul 16, 2007, at 8:05 AM, Ate Douma wrote:
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
YAY!!!!
Right :)
- 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
I'd very much like to help with this and might even have enough time :-)
The last time I looked (1.5 years ago) I wanted to go for a security
model that worked entirely on Permissions. IIRC the objection at that
time was that the non-Permission scheme could deny as well as grant
permissions: I think that we can do that with Permissions as well.
There's a apache directory subproject called Triplesec that I'm also
trying to find enough time to work on and I think may have some useful
ideas on how to organize permissions and possibly other aspects of this.
Please bring them up, I'm open to discuss this again and properly so now.
As its been a long time, can you also please describe why you think we
can/should base our security model (entirely) on Permissions?
Our current Constraints based model has served us well, so would we be able to
maintain that too (possibly on top of a Permissions based scheme)?
- multiple authentication/authorization schemas to support truly
separated access & maintenance of "communities" in one portal
I'm not quite sure what you mean here, but it sounds interesting.
Being able to "deploy" multiple sites in one portal, each with their own set of
users and security scheme.
This will allow to use a single portal instance (although possibly clustered) for different (set of) groups/users/customers, e.g. "communities", each with their
own personal/separated "site".
- 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
I definitely want to help with this for Geronimo. I think that a more
coherent build will be a big help with this :-)
+1
One of my targets for Jetspeed 2.2 definitely is proper integration with
Geronimo.
- Jetspeed "light" (no need for database persistence and much
simplified page/site management)
- I think that moving to jpa for persistence would be a good idea. I
think moving to java(ee)5 is reasonable too, but it may be possible to
use openjpa in a 1.4 environment (I'm not sure). At least if we can move
to java 5 I think I can help with this.
With the planned support for JSR-286 Portlet API 2.0, which requires Java 5
too, leaving 1.4 behind is one of the consequences.
About moving to JPA: yes. I'm all for replacing OJB with either JPA or JDO2.
Personally, I think JPA still has a long way to go before it can match JDO2,
and JPA has some severe limitations too.
If we can be sure enough JPA can cover our needs though and be performant too,
its OK with me.
But please note: what I proposed above for a Jetspeed "light" actually is (also to) separate out database persistence altogether by factoring out those
dependencies from our component model so we can also provide an memory or xml/file based storage model.
thanks
david jencks
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
