How to maintain different portlet codebases for Liferay 6.0 and 6.1
In Liferay 6.1, the ServletResponseUtil class has been moved to a different package than in Liferay 6.0:
//Liferay 6.0,
// this class lives in util-java.jar in the default tomcat web app, /webapps/ROOT/lib.
import com.liferay.util.servlet.ServletResponseUtil;
//Liferay 6.1
// class lives in portal-service.jar in directory tomcat-7.../lib/ext/
//import com.liferay.portal.kernel.servlet.ServletResponseUtil;
The class is used in our code as follows:
String result = personComponentImpl.process(request);
response.setContentType("text/xml");
try {
ServletResponseUtil.write(response, result);
}
catch (Exception e) {
if (_log.isWarnEnabled()) {
_log.warn(e, e);
}
}
I need to maintain and improve a portlet that was written for the Liferay 6.0 release. We are now considering upgrading to 6.1, but during internal testing of the portlet I found that there are several lines of code where the above dependency is broken. At runtime, there are ClassNotFoundExceptions in 6.1.
My eclipse project is set up for 6.0 in mind.
What should I do now?
-
Maintain two different branches of portlet code. It is doable, but it can be too much effort in the long run.
-
Maintain two different Eclipse projects with the same codebase but different build paths (this is just a general strategy, may not work)
-
Include smart hack in java code, easily build for 6.0, once for 6.1 (maybe a factory ... it's just a vague idea)
-
Include a new ant task that builds + deploys for 6.1, although Eclipse is configured to build for 6.0
-
Remove the dependency on the ServletResponseUtil class altogether, use a different class that does the same thing as ServletResponseUtil.
-
Do something else
source to share
Since ServletResponseUtil is no more than 350 lines long, extremely verbose and even flawed implementation response.getOutputStream().write(data);
, I would choose to "use another class that does the same."
Perhaps you should combine that with a little "do something else" and never rely on the stability of the Liferay API.
source to share