This sounds really good to me. That's it, what i was looking for, as i was starting with pluto. It'll be a big help for all the people working with pluto and developing portlets.
Another big point is, as elliot already said, that portlet wars shouldn't be pluto specific. That's IMHO against the idea of standardisation of JSR 168 compatible portlets. - Develope a portlet, package it as a war, test it with pluto, and take it to the portal of your choice without changing anything. Christian Elliot Metsger wrote: > > > Charles Severance wrote: >> Eliott - I don't get it. >> >> Sakai already does hot deploy with Pluto 1.1 - all of the code Sakai >> has added that runs at the moment of the init of the PortletServlet - >> runs on a re-deploy of the webapp and re-registers the portlet with >> Sakai - viola - it is there. So hot-deploy is possible. > > Sure, let me back up and expound on Eric's reply. > > To deploy a portlet in a Pluto 1.1 based portal, there are three steps: > > 1) Assembly of the portlet war file - the container-specific munging of > web.xml and subsequent packaging into a war. > 2) Deployment of the portlet war file to the portal - currently done by > plopping the assembled war into /webapps. > 3) Registration of the portlet war with the container - currently > automated by PortletServlet's init() - this is what you're referring to > above. > > So in short I'm proposing to put code into the Pluto container to > automate items 1) and 2). The idea is that the developer packages up > the portlet into a war, with _no Pluto information in web.xml_. Places > this war into a specific directory on the filesystem (either by copying > it or uploading it via an admin tool). Pluto monitors the directory, > and when it senses a war has been added, it will perform steps 1) and 2) > programatically: the war is assembled and then deployed to the servlet > container with no intervention by the developer/administrator. > > None of this would prevent the current way of doing things: placing a > manually assembled war file into /webapps. My position is that there is > a better way to do assembly and deployment: better for the portlet > developer, and better for the portlet container, and better for the > portlet community at large. > > Right now assembly is performed manually by the developer (either by vi > or by Maven or Ant mechanisms), and this has a couple consequences: > 1) Pluto-specific internals are exposed, and so Pluto container must > (should?) support older web.xml formats as the container evolves. The > reality is that right now this burden is being borne by the portlet > developer when it should be borne by the container (IMO). > 2) Portlet wars are being packaged and distributed with pluto-specific > elements, reducing portability. > 3) And then there is the headache that new portlet developers encounter: > the idea of assembly - some manual steps taken during packaging - is > foreign. > > Does this explanation help? Are these features worth cycles? Etc etc. > > Elliot
