java - How to maintain different portlet codebases for Liferay 6.0 and 6.1 -


in liferay 6.1 class servletresponseutil has been moved different package in liferay 6.0:

//liferay 6.0,  // class lives in util-java.jar in 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 used in our code 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 maintain , improve portlet written liferay 6.0 release. considering upgrading 6.1, during internal testing of portlet discovered there few line of code above mentioned dependency broken. there classnotfoundexceptions on 6.1 @ runtime.

my eclipse project set 6.0 in mind.

what should now?:

  • maintain 2 different branches of portlet code. doable might effort in long run

  • maintain 2 different eclipse projects 1 code base, different build paths (this general strategy, might not work)

  • include clever hack in java code, build 6.0, once 6.1 (maybe factory...this vague idea)

  • include new ant task builds + deploys 6.1, although eclipse set build 6.0

  • remove dependency on servletresponseutil class altogether, use class same servletresponseutil.

  • do else

since servletresponseutil not more 350 lines long, extremely verbose , buggy implementation of response.getoutputstream().write(data);, opt "use class same".

perhaps should combine little "do else" , never rely on stability of liferay api.


Comments

Popular posts from this blog

delphi - How to convert bitmaps to video? -

jasper reports - Fixed header in Excel using JasperReports -

python - ('The SQL contains 0 parameter markers, but 50 parameters were supplied', 'HY000') or TypeError: 'tuple' object is not callable -