-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Craig, i would like moving toward the "jsr-286". What David has already said, everyone must decide himself on what implementation he want's to work. But for the jsr-286 implementation it is important to make a cut to the 168 implementation. I don't know what version is best for.
Torsten David H. DeWolf schrieb: > > > [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 >>>> >>>> >> > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGnLxO0Ji0BqEIlIURAgX/AJ4rKefMJds0qKV3zwPItvaoUMBq3QCdHucL 6pEXFvTr+vdArIPA7IqrPJg= =wc8D -----END PGP SIGNATURE-----
