On 5/7/10 9:02 AM, Gary Weaver wrote:
Just so you know UI changes are usually the last thing to happen in a uPortal development cycle and never finalized until we get to the RC stage, doing integration work before an RC is never recommended.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).
The previous fluid and jQuery versions are always available in RSW so if your portlets work on 3.2 with those libraries they will work on 3.3, you just may have to do some adjustment for CSS changes in the default skin between the two versions of uPortal.* 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.
That should be doable from uPortal 3.0 onwards. You need to create essentially you're own version of the uportal-ear and portlet-overlays sections of uPortal. Point it to your version of the uPortal WAR and configure an overlay for each portlet WAR you're using. Run "mvn package" to get the EAR and deploy that.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.
I can't say what the official way will be in 3.3. We'll have that figured out by the first RC :)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?
I'm not sure what you're referring to. There are .channel files in uPortal 3.x which can be used with the import tools to publish portlets. Is that what you're thinking of?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
smime.p7s
Description: S/MIME Cryptographic Signature
