Craig, I've been anticipating working with an alpha or beta of a branch that is working towards 286 compatibility, but I am just wondering about the status of the current 286-COMPATIBILITY branch. I have been holding off on developing my portal until there is at least a somewhat stable version. If this is the case with the current 286 branch, I'll start working with it and report or help fix any issues that I come across. Do you think that the current branch is at least good enough to get started with, or should I wait until some of the recent updates from trunk get applied?
Thanks, Ben On Mon, 2007-07-16 at 14:13 -0400, [EMAIL PROTECTED] wrote: > > David, > > Thanks for reminding me about this. Yes, we can all go off in any > number of directions if we want. > > I intend to start focussing my efforts on the 286-COMPATILIBITY > branch. merging the code with the current trunk and pushing out a > Pluto 2.0 alpha or beta release. I hope that others in the Pluto > community will join me in that effort. > /Craig > > > > > "David H. DeWolf" > <[EMAIL PROTECTED]> > > 07/16/2007 12:44 PM > Please respond to > [email protected] > > > > > To > [email protected] > cc > > Subject > Next few releases > (was Re: [VOTE] > Pluto 1.1.4 > Release) > > > > > > > > > > > [EMAIL PROTECTED] wrote: > > > > > I am very much against moving toward a 1.2.0 release. We should not > get > > mired in a 1.2.x release cycle of a JSR-168 impl. We need to start > > moving toward jsr-286. The jsr-286 EG will be releasing a public > draft > > soon that is feature complete. Torsten's work in the 286 branch has > > almost caught up with the draft spec. Both Exo and JBoss portal has > > preliminary (alpha/beta) jsr-286 releases. We should not be that > far > > behind. > > There's no reason why we can't do both. OS is about scratching your > own > itch. If someone wants to work on 1.2.x, then go for it. If you > want > to focus on 2.x, then by all means - do it! Shoot, if someone wanted > to > dig up 1.0.x they are welcome to do that as well. > > David > > > > /Craig > > > > > > > > *Elliot Metsger <[EMAIL PROTECTED]>* > > > > 07/16/2007 10:00 AM > > Please respond to > > [email protected] > > > > > > > > To > > [email protected] > > cc > > > > Subject > > Re: [VOTE] Pluto 1.1.4 Release > > > > > > > > > > > > > > > > > > Looks like the changes snuck in between the 1.1.2 and 1.1.3 release > with > > PLUTO-350 (r523130) - the relative URL provider. I'm thinking we > could > > probably take it out, but I haven't taken a thorough look. > > > > Of course, since the change is out there with 1.1.3, 1.1.3 users who > > move to 1.1.5 will be broken. > > > > We could re-release this 1.1.4 candidate as a 1.2.0, and put a note > on > > the website noting the 1.1.3 incompatibility. Or just release 1.1.5 > and > > retract 1.1.3? > > > > Elliot > > > > David H. DeWolf wrote: > > > -1 > > > > > > 1.1.3 and 1.1.4 should be backwards compatible (binary and > runtime > > > compat). This looks to me like we introduced an incompatibility. > In the > > > meantime, is there a workaround we can use in order to get 1.1.5 > > > released without this incompatibility? > > > > > > This type of change can be added to 1.2.x BUT should be > specifically > > > mentioned in an "upgrade" guide. > > > > > > David > > > > > > Charles Severance wrote: > > >> Elliot, > > >> > > >> Switching from 1.1.3 to 1.1.4 - Sakai compile fails with the > following: > > >> > > >> > > /Users/csev/dev/sakai/portal/portal-render-impl/impl/src/java/org/sakaiproject/portal/render/portlet/services/SakaiPortalCallbackService.java:128: > > > > > > >> > > > org.sakaiproject.portal.render.portlet.services.SakaiPortalCallbackService.SakaiPortletURLProvider > > > > > >> is not abstract and does not override abstract method > > >> isSecureSupported() in org.apache.pluto.spi.PortletURLProvider > > >> class SakaiPortletURLProvider implements > PortletURLProvider > > >> > > >> Has an API changed? I am happy to update Sakai, adding methods > or > > >> whatever - let me know if this was an intentional change. > > >> > > >> /Chuck > > >> > > >> > > >
