AskSteve has covered quite a few topics on general software development, but I recently received an interesting query about portal-based development in particular:

“We’ve been developing sets of portlets which gather information from different sources, run simulations and display the results in a variety of map and graph based methods. These have been developed using the Sakai portal infrastructure but we’d like to be able deploy the portlets in LifeRay and other platforms.

What should we be aware of when trying to port to another portal infrastructure, what techniques can we use to ensure everything is working correctly, and where can we find out more about which portal platforms we should be testing deployment against?”

Since this is such an interesting question, and one that deserves and requires a comprehensive response, I decided to write a guide about it. In short:

• JSR-168/JSR-286 compliance: this is the key. Ensuring compliance with the JSR-168/286 specifications, which provide a common development model for portlet development, will greatly assist your portlets in running across a number of portal platforms (any worth their salt will support these specifications). You mention you have a number of portlets: if they expect to communicate with each other then JSR-286 is likely the one to target since it supports inter-portlet communication explicitly, whereas JSR-168 does not.
• Decide which portal platforms to support: ask your intended user community about their requirements here. They may be using a particular set of platforms already, and possibly  have specific requirements that indicate which ones you should support. Many platforms support a whole host of other features including content management – are there any other features you’ll need?
• Decide which portal containers to support: for example, Tomcat or Glassfish. Again, this should come back to what your user community requires or is currently using.
• Have a logical and separate test set-up: instead of having a bundle of testing containers with a number of portlet platforms deployed, which is messy and can lead to confused results, have separate installations of each portlet framework and container permutation for clearer log files and cleaner testing.
• Use a test framework: the browser-based test framework Selenium is worth considering, since it allows you to test web-based applications like portlets, and even generate JUnit tests. Coding direct JUnit tests is also possible, and Spring MVC has its own test framework.
• Involve your community throughout: why not ask keen members of your community if they’d be willing to beta test your portlets? You get testing effort and community feedback, and your portlets improve!

I hope this helps – ’til next time!