Good points, The Maven and Spring work are pre-requisites for the larger change which is moving to Pluto 1.1 or 2.0 (depending on what is available when). The big changes that will be included in a 3.0 release are Maven for a build system, more coherent architecture via Spring and Pluto 1.1 (possibly 2.0 with 286 support). More specifically the goals outlined at the barcamp in June our outlined here: http://www.ja-sig.org/wiki/x/tgFl
One part of this is soliciting ideas from folks familiar with the internals of uPortal as to how we want to do that Pluto upgrade. Do we keep the concept of the channel adapter and add features to the IChannel interface to account for the portlet features that channels don't support? Do we change the layout/rendering architecture to support two similar but separate concepts of channels and portlets and make them equals in the internals of the framework? I don't think this will be an easy question to answer but I would very much appreciate as much discussion on it as possible. I hope that helps, -Eric Cris J Holdorph wrote: > I know there was discussion of up3 at the barcamp at the ja-sig > conference in June. Unfortunately, I had a 3.5 hour workshop to > deliver during that time so I was unable to participate. > > What I don't understand is why the initial effort is being put towards > the activities you mention and converting uPortal to Pluto 1.1 (or > hopefully pluto 2.0) is not mentioned at all. > > JSR 286 was Finalized on August 27, 2007 (that was the date votes > closed). If we release uPortal 3.0 nearly 1 year later in summer 2008 > without JSR 286 support, I think that will send an unintentional > message to Portal consumers/adopters/developers. > > So, while I can appreciate the great value in the conversion to Maven, > and Spring Web MVC Dispatcher Servlet, I would to know more about how > uPortal 3 is going to improve on it's support of Portlets (or even > Channels if that was worthwhile). > > ---- Cris J H > > Eric Dalquist wrote: >> There hasn't been much traffic on about the uP3 work since the >> conference and hopefully this is the first of many messages resolving >> that problem. >> >> Work has been happening on converting the trunk of the uPortal >> project to use Maven 2 as the build system. This has been a complete >> conversion so much of the directory structure has been re-arranged. >> The work is complete and, with a little testing from folks on this >> list, ready to be merged from the 'working-maven' branch back into >> the trunk. I would encourage everyone to check out from the branch >> and give it a try. There is a build.xml file that at this point >> replicates the main Ant targets used by developers pre-conversion, >> initportal is still all you need to run to get everything going after >> setting up build.properties. Please provide feedback, there are bound >> to be rough spots and missing developer features and hearing from >> developers is how they will be fixed. >> >> One known issue: Ant 1.7 will not work, there is a nasty little bug >> that will be fixed in 1.7.1, for now use Ant 1.6 >> >> >> With this progress and new build system I need to get it properly >> documented and have a place for documentation as this effort moves >> forward. After looking through the wiki and chatting in IRC I have >> the following proposal. All documentation in the uPortal 3 space >> related to the uPortal 3 sandbox code would be consolidated and moved >> under a uP3-Sandbox page then the uPortal 3 space would be used for >> documentation of the goals of this effort and documentation of >> changes as they happen. I'd like to get other thoughts and >> suggestions as to how to deal with the wiki documentation as well. >> >> >> The next step in the uP3 effort is consolidating the multiple Spring >> configurations in the project and replacing the inner workings of the >> static services with Spring configurations. Also related to this >> would be looking at using a Spring DispatcherServlet as the root >> servlet for uPortal, using Acegi to replace security.properties and >> similar tasks. Along side the documentation effort I'll be detailing >> these as sub-tasks of the root Spring related issue: >> http://www.ja-sig.org/issues/browse/UP-1789 I'll post an update when >> I get these sub-tasks details to look for some help in getting them >> done. >> >> >> -Eric >
smime.p7s
Description: S/MIME Cryptographic Signature
