Raphael Luta wrote:
> "Diethelm Guallar, Gonzalo" wrote:
> >
> > > Several things have changed regarding security and users, but nothing
> > > dramatic. As far as I can see, references in a few classes
> > > (about 5) have to be adapted.
> > >
> > > If nobody on the list objects, I'll migrate jetspeed to the
> > > current turbine
> > > version and send the patches to one of our "writers" for check in.
> > >
> > > Comments?
> >
> > There is an imminent merge of a Turbine branch with new code
> > for users and security. I think you would be better off waiting
> > for that.
> >
> > Also, I would place a high priority on the work of merging all
> > of the latest Jetspeed changes into the HEAD branch, so that
> > things compile again.
> >
>
> I agree. Merging the branches and landing this merge should be first
> priority (and I think Santiago is tackling this). Once we have recovered
> from this landing, update the Turbine dependencies in 2 areas:
> user management and templating.
>
I have not found any specific way to switch branches in CVS, so I think the
process will be something similar to:
- Create a new branch, rooted at HEAD at the point that pre-proposal-0003-no-psml
was created. Let's call it proposal-0003-new-peers, for instance. Also, tag the
pre-branch moment as before-proposal-0003-branches
- Patch the differences between HEAD and -r before-proposal-0003-branches into
this new branch, so that effort done by Kevin stays in this new branch.
- Keving should be aware of the process, as well as other people in HEAD. If they
want to keep working on this code, they wil have to go to the new branch.
- Reset HEAD to -r before-proposal-0003-branches and commit, so that,
effectively, HEAD will be back to the branch point.
- Merge changes in pre-proposal-0003-no-psml to the new HEAD.
(I'm still thinking into this. CVS is very tricky sometimes. I would like that
somebody more experienced would tell me if this is right or not.)
>
> Landing the new user model in Jetspeed will require testing of all the
> user registration/authentication process to make sure there are no hidden
> bugs even if the code does compile. If you want to start working on
> improving this, I think you can try to use the security-01-branch of Turbine
> against the pre-proposal0003-no-psml branch of Jetspeed and cope with changes
> produced by the merging of these branches in their respective trunks.
>
Also, note that in pre-proposal-0003-no-psml there are some comments, as I tried
this work before commiting. I decided to go back because authentication did not
work.
NOTE: be careful to upgrade village.jar (and maybe other jars changed in Turbine)
during the tests. I forgot that.
NOTE: In the branch, I copied jyve screens, layouts,... to
org.apache.jetspeed.turbine.* so that we can modify them freely under version
control, to ensure that changes needed to update Turbine do not make us carry
further a patched version of jyve. Further integration with jyve can be attacked
later, when jyve is also in synchrony with Turbine. After we test, jyve.jar
should be taken out of the cvs repository.
>
> I've started working on a template aware implementation of the jetspeed
> engine.
>
That is very nice. When you have it going we need to imagine a way to integrate
Cocoon as a template engine, that would transform XML instead of reading a
template file.
>
> --
> Rapha�l Luta - [EMAIL PROTECTED]
>
> --
> --------------------------------------------------------------
> Please read the FAQ! <http://java.apache.org/faq/>
> To subscribe: [EMAIL PROTECTED]
> To unsubscribe: [EMAIL PROTECTED]
> Archives and Other: <http://java.apache.org/main/mail.html>
> Problems?: [EMAIL PROTECTED]
--
--------------------------------------------------------------
Please read the FAQ! <http://java.apache.org/faq/>
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Archives and Other: <http://java.apache.org/main/mail.html>
Problems?: [EMAIL PROTECTED]
