geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Petersson <>
Subject Re: Liferay as a Geronimo Plugin
Date Fri, 18 Jul 2008 11:12:01 GMT
Gianny Damour wrote:
> On 14/07/2008, at 5:17 PM, Peter Petersson wrote:
>> Gianny Damour wrote:
>>> Hello Peter,
>>> This is great news for Liferay developers!
>>> IMHO, one of the pain points with Liferay development is the time it 
>>> takes to build, pack and deploy a WAR to Liferay. Even if Liferay is 
>>> not so bad on this front when compared with other portals, a typical 
>>> build-deploy-test cycle is way too time consuming and hence 
>>> seriously impacts productivity. It would be fantastic to have an 
>>> in-place WAR development mode in Geronimo. What do you think?
>> I guess you are referring to working with/in the liferay ext 
>> development environment (?). I know to little of Liferay internals 
>> (and Geronimo for that mater) to be sure exactly what you are looking 
>> for, but I am sure the Liferay team is working hard on making there 
>> development environment easier and faster to work with. Maybe you can 
>> elaborate a bit more on what you are thinking of.
> Hello,
> My understanding is that each time that you make a change, you need to 
> build a WAR; drop it in the deployment folder of Liferay; Liferay 
> scans and transforms the WAR (looking for portlets, themes et cetera); 
> it then hands it over to Geronimo for deployment. These deployment 
> steps are time consuming, especially during development.
> What I had in mind is a Geronimo plugin allowing the in-place 
> deployment of WARs to Liferay:
> 1. I define a specific WAR project structure;
> 2. I set-up my IDE to work against this well-known WAR project structure;
> 3. I implement my portlets and my IDE compiles the sources to the 
> right folder of the WAR project structure;
> 4. I deploy to Geronimo my WAR project structure;
> 5. A custom ModuleBuilder identifies that this is a liferay WAR 
> project structure; looks for the relevant Liferay components; and 
> deploys it in-place.

Maybe this is something on the line of what you are looking for:
I have set up a small maven "test" project that wraps liferay portlets, 
themes et cetera into deployable Geronimo plugins. Looking at the logs 
wile deploying a liferay portlet geronimo plugin it seem to handle the 
deployment correctly and Liferay notifies you about a available update 
but looking in to it in the "Update manager" admin tool in liferay the 
Installation status never changes from "Installation in progress" so I 
suspect there is some configuration problem or module missing In my 
Geronimo Liferay server assembly for it to work correctly. Hopefully 
this is resolvable but at the moment I don't have a clue about whats 
causing the problem.
Using this approach It would probably not be to hard to totally automate 
the installation process for Liferay "extensions" by using GShell (or is 
there a way to deploy to Geronimo plugins via maven directly ?)

I was thinking of testing the portlet plugins on the new Liferay 
Geronimo (5.0.1/2.1.1) assembly available from Liferay but there is a 
(issue reported) problem with user authentication using derby db as 
back-end so I was unfortunately not able to see if it worked better on 
that one.

    peter petersson 
>> Personally I will look in to setting up a maven project for building 
>> Liferay portlets and have them deployed to Geronimo in some automated 
>> way instead of working with the ext environment, maybe this is what 
>> you are looking for? I don't know yet how the deployment could be 
>> done but I guess that I will making use of Liferays hot-deploy 
>> mechanism and/or if possible find some way to make use of Geronimo:s 
>> plugin concept. If possible I would certainly prefer the plugin 
>> solution.
> I believe that the Liferay hot-deployment mechanism is way too slow in 
> development.
> Does that make sense?
> Thanks,
> Gianny
>> Maybe the deployment could be done in a similar way of what we have 
>> done with the roller-themes plugin in the geromimo-roller project ?
>> see
>> regards
>>   peter petersson
>>> Thanks,
>>> Gianny
>>> On 14/07/2008, at 4:11 AM, Peter Petersson wrote:
>>>> I have posted a feature issue containing the build code over at 
>>>> regards
>>>>   peter petersson
>>>> Peter Petersson wrote:
>>>>> Hi
>>>>> With the help of David J custom server assemblies document ( 
>>>>> ) 
>>>>> and my experience working with David on the roller plugin I have 
>>>>> manage to put together a Liferay ( ) 
>>>>> plugin. For now the plugin is with liferay 5.0.1 rc1 on G 2.1.1 
>>>>> and consists of the following maven artifacts
>>>>> * geronimo-jetty-liferay -- A minimalistic server assembly with 
>>>>> the geronimo kernel the lifray jetty plugin and the geronimo 
>>>>> console plugin.
>>>>> * liferay-jetty -- The liferay jetty plugin built on the lesslibs 
>>>>> liferay-portal war pulling in dependencys like lifray -kernel, 
>>>>> -service and -portlet.
>>>>> * geronimo-tomcat-liferay -- A minimalistic server as above but 
>>>>> with the liferay tomcat plugin.
>>>>> * liferay-tomcat -- The liferay tomcat plugin as liferay-jetty 
>>>>> above but with tomcat.
>>>>> * liferay-derby -- The liferay derby db backend plugin.
>>>>> * lifray-portal -- The liferay portal war fetched from liferay and 
>>>>> pulled in to a local maven repos.
>>>>> * liferay-portal-lesslibs -- A overlay of the liferay portal war 
>>>>> with filtered lib jars making use of some geronimo builtins instead.
>>>>> The geronimo-tomcat-liferay server seems to work fine but the 
>>>>> jetty equivalent has a issue in the login page. When I have ironed 
>>>>> out the jetty issue, cleaned up the code, made some additional 
>>>>> improvements and put together a simple readme with build 
>>>>> instructions ;) I am thinking of wrapping it up and first of all 
>>>>> contribute it to the liferay community ( as suggested by david in 
>>>>> ) to
>>>>> if they are interested in it for there geronimo integration.
>>>>> Anny suggestions, opinions, tips or help to pull this together in 
>>>>> the best way possible are appreciated.
>>>>> regards
>>>>>  peter petersson

View raw message