> >> 2. I need to be sure our current portlets could be deployed and still run. >> >> We deployed most from the admin tool in uP 2.5.3.2, but we'd want to >> automate the publishing of the portlets after each time HSQL is started. >> What is the current way to do this? >> > A portlet is a portlet. If your JSR-168 portlet works in uPortal 3.x it will > continue to work. Unless your portlet is somehow using a uPortal specific API > you shouldn't need to be worried about testing portlets between versions of > uPortal. >
Actually, I was just asking about automating portlet republishing, not about whether the portlet java and JSP source compiles correctly. And as an aside, there have been and will continue to be changes between uPortal versions that either require or beg portlet changes, even though the portlets are JSR-168 compliant: * The CSS has changed between versions of uPortal which can mess with the UI of the portlet such that it doesn't render the same way (we are jumping between uP 2.5.3.2 and 3.3 so it is even more of a concern). * We'd want to change portlets to use the ResourceServingWebapp. * Instead of using prototype as some of our portlets do now, we'd want to change them to use JQuery and have JQuery served by ResourceServingWebapp. * Changes in Fluid versions, jQuery versions, etc. provided with newer versions of uPortal served by the ResourceServingWebapp and/or via skin changes could require or beg portlet changes. I know that a few CSS classes used for tabbing were just renamed (and not deprecated) between the early pre-release of Fluid (what is later called Infusion iirc) that earlier versions of uP 3.x were using, and I'm not sure what version of uP contains the updated FSS with these name changes. We the FSS tab stuff in Mail Portlet (in uP 2.5.3.2 I had to tack it into our CSS), so I'm assuming changes in the FSS version might require additional changes for that portlet. But back to the question of automating portlet (re)publishing (and additional question on portlet (re)deployment)... basically it would be nice to have a CI build rebuild the portal, portlets, and auto-redeploy and auto-republish all of the portlets. For redeploying portlets, I think that the maven-uportal-plugin at least used to be able to be used for deploying portlets in uP 3.1.1 (according to Yale's documentation). I assume that "ant deployPortletApp" is still the official way to do it in 3.2.1, but that maybe maven-uportal-plugin will be used in 3.3 (?) and we'll just have to change things in all of our portlet deployment scripts to reflect that. Is that correct? But for republishing portlets, there used to be support in uP 2.5.3.2 (although we've not used it in quite a while) for channel descriptor files to be used so that portlets could be autopublished. However, I'm not sure how to automate republishing portlets in 3.2.1 and I don't know if that will change in 3.3. Could you explain? Thanks! Gary -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
