Как поддерживать различные баз кода портлетов для Liferay 6.0 и 6.1

Question

В Liferay 6.1 Класс ServletResponseUtil был перемещен в другой пакет, чем в 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; 

Класс используется в коде, как это :

String result = personComponentImpl.process(request); 
    response.setContentType("text/xml"); 

    try { 
     ServletResponseUtil.write(response, result); 
    } 
    catch (Exception e) { 
     if (_log.isWarnEnabled()) { 
      _log.warn(e, e); 
     } 
    } 

Я должен поддерживать и улучшать портлет, который был написан для выпуска Liferay 6.0. Теперь мы рассматриваем возможность обновления до 6.1, но во время внутреннего тестирования портлета я обнаружил, что существует несколько строк кода, где указанная выше зависимость нарушена. Во время выполнения есть ClassNotFoundExceptions в 6.1.

Проект моего затмения настроен для 6.0 в виду.

Что мне теперь делать ?:

• поддерживать две различные ветви кода портлета. Это выполнимо, но может быть слишком много усилий в долгосрочной перспективе

• ПОДДЕРЖАНИЯ два различных проектов Eclipse, с одной кодовой базой, но с разными путями сборки (это только общая стратегия, не могут реально работать)

• Включите умный взломать код Java, легко построить для 6.0, один раз для 6.1 (возможно, фабрику ... это всего лишь неопределенная идея)

• Включите новую задачу ant, которая строит + развертывает для 6.1, хотя Eclipse настроен для построения для 6.0

• Re переместите зависимость от класса ServletResponseUtil вообще, используйте другой класс, который выполняет то же самое, что и ServletResponseUtil.

• ли что-то еще

Answer 1

Поскольку ServletResponseUtil не намного больше, чем 350 строк длиной, очень многословной и даже багги реализации response.getOutputStream().write(data);, я выбрал бы «использовать другой класс, который делает то же самое».

Возможно, вам следует объединить это с небольшим количеством «сделать что-то еще» и никогда полагаться на стабильность API Liferay.