How to maintain different portlet codebases for Liferay 6.0 and 6.1

Question

In Liferay 6.1 The class ServletResponseUtil 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 like this:

    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 have to maintain and improve a portlet that was written for the Liferay 6.0 release. Now we are considering upgrading to 6.1, but during internal testing of the portlet I discovered that there are a few line of code where the above mentioned dependency is broken. There are ClassNotFoundExceptions on 6.1 at runtime.

My eclipse project is set up for 6.0 in mind.

What should I do now?:

• Maintain two different branches of the portlet code. This is doable but might be too much effort in the long run

• Maintain two different Eclipse projects with one code base, but with different build paths (this is only a general strategy, might not really work)

• Include a clever hack in the java code, to build easily for 6.0, once for 6.1 (maybe a factory...this is only a vague idea)

• Include a new ant task that builds + deploys for 6.1, although Eclipse is set up to build for 6.0

• Remove the dependency on ServletResponseUtil class altogether, use another class that does the same as ServletResponseUtil.

• Do something else

Answer 1

Since ServletResponseUtil is not much more than a 350 lines long, extremely verbose and even buggy implementation of response.getOutputStream().write(data);, I would opt for "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.