Raymond Augé's guest appearances

Raymond Augé

Radio Liferay

Michael Young

Juan Gonzalez

Brian Chan

Dennis Ju

Jorge Ferrer

Kristoffer Onias

Victor Ware

James Falkner

RL054 Scott Nicklous

Neil Griffin

Jens Bruhn

Thomas Schweiger

Bryan Ho

Stian Sigvartsen

Brett Swaim

OwlTail

 	A continuation of last week's episode, Milen Dyankov stepped in as a co-host and helped me ask the right questions: Ray Augé answers all sorts of questions about the Modularization in Liferay 7 and what to do with your existing investment in Liferay Plugins - what to do with the plugins you already have, where you will have to re-learn and what you can, should or shouldn't continue to do..  	As we recorded this on site at Devcon, you'll hear more background noise than usual - Auphonic did their best to clean the recording, and they did a great job.  	Here are some of the topics that we talked about:  	Portlets:   		If you're not interacting with Liferay, e.g. a pure JSR-286 portlet: No changes required  		JSF: Last kinks are worked out - test the more complex the JSF implementation is  		If you're using Liferay API: You'll have to resolve API changes - e.g. recompile and check if the API is still valid. Check these breaking changes - well documented, huh? And even better: The document is machine-readable and there will be migration tools (future episode planned) 		  				If the service is still in Liferay's core: No change needs to be made.  				If the service is now in a module: Check if the package was updated. Fix if necessary and if the migration tool didn't do it for you.    		Circumstances under which Liferay automatically "translates" WAR file into OSGi bundles - and the caveats  		Extensions to Liferay MVC portlet: Check for the nature of those changes  		The use of CDI - especially when the appserver's implementation/resources are utilized - still requires some work.  		Everybody who's doing really advanced stuff on sophisticated frameworks is welcome to try it out now and let us know now if there are any problems that remain  		How little of OSGi can I get away with?   	Hooks   		Many of the hooks - especially on services and models will continue to work, but won't have more power than in 6.2. They're prime candidates to be converted to an OSGi module as this will enable them to tap into a lot more extension points in Liferay 7.  		Struts Action Hooks probably need changes - while they still work, most of the underlying actions have been reimplemented without Struts \o/, so possible overloads in Struts actions won't be taken into account for the new implementation. 		  				(most likely: You need to convert to an MVC Command, injected as an OSGi module. There are samples available)    		Liferay 7 has a lot more extension points than prior versions. The documentation is being made available on dev.liferay.com - obviously this is still work in progress, but is scheduled to be there until release.  		How can IDE and other tools help identifying which extension points are in use? And how to make lots of friends within the Liferay Community  		Overriding Language Keys is quite simple - choose "global" or "per portlet" - those are the two available scopes that a translation can live in. 		  				For migration you might have to decide which scope your changes should go into.  				Encoding still is done in UTF-8    		JSP-Hooks: The elephant in the room: Seems to be very popular, but always has aimed at the implementation rather than to an API. 		  				As drastic UI changes happened in Liferay, these implementation need to be implemented on the new infrastructure, leveraging new techniquest (e.g. Lexicon). Also, most of the functionality has been moved into modules - JSP-Hooks only affected the core jsps...  				New options: JSPs can be deployed as proper OSGi bundles.  				There's still danger because technically the implementation is unchanged compared to earlier versions  				New fragment modules enable you to override JSPs in any portlet - not only core ones. 				But you shouldn't limit yourself to JSP-overrides: There are more ways to change Liferay's UI, e.g. 				  						replace the render-phase of a portlet through a portlet filter.  						A new "dynamic include" API to inject extension points at very specific places - e.g. at those UIs commonly targetted by overrides. (let us know which are missing) 						Application Adapters       	Ext   		Ext Plugins work just like before (in core). But most likely, the implementation has changed anyway, so that you need to make sure your code is still valid for the current version - but that's what you expected when you started writing that ext anyways, right?  		Of course you'll have to check if your changes still are contained in Liferay core. If they're extracted to a module, ext won't be yours any more (for these changes) 		Ideally, ext will be the easiest plugin, as it probably will be a lot smaller than before.   We haven't covered all possible questions and are planning a "Listener Questions" episode. Please ask your questions in the comments to the blog article for this episode to get them answered in the next episode with Ray.

A continuation of last week's episode, <a href="https://www.liferay.com/web/milen.dyankov" rel="nofollow" target="_blank">Milen Dyankov</a> stepped in as a co-host and helped me ask the right questions: <a href="https://www.liferay.com/web/raymond.auge" rel="nofollow" target="_blank">Ray Augé</a> answers all sorts of questions about the Modularization in Liferay 7 and what to do with your existing investment in Liferay Plugins - what to do with the plugins you already have, where you will have to re-learn and what you can, should or shouldn't continue to do.. 	As we recorded this on site at Devcon, you'll hear more background noise than usual - <a href="https://auphonic.com" rel="nofollow" target="_blank">Auphonic</a> did their best to clean the recording, and they did a great job. 	Here are some of the topics that we talked about: 	Portlets: <ul> <li> 		If you're not interacting with Liferay, e.g. a pure JSR-286 portlet: No changes required</li> <li> 		JSF: Last kinks are worked out - test the more complex the JSF implementation is</li> <li> 		If you're using Liferay API: You'll have to resolve API changes - e.g. recompile and check if the API is still valid. Check <a href="https://github.com/liferay/liferay-portal/blob/master/readme/7.0/BREAKING_CHANGES.markdown" rel="nofollow" target="_blank">these breaking changes</a> - well documented, huh? And even better: The document is machine-readable and there will be migration tools (future episode planned) 		<ul> <li> 				If the service is still in Liferay's core: No change needs to be made.</li> <li> 				If the service is now in a module: Check if the package was updated. Fix if necessary and if the migration tool didn't do it for you.</li> </ul> </li> <li> 		Circumstances under which Liferay automatically "translates" WAR file into OSGi bundles - and the caveats</li> <li> 		Extensions to Liferay MVC portlet: Check for the nature of those changes</li> <li> 		The use of CDI - especially when the appserver's implementation/resources are utilized - still requires some work.</li> <li> 		Everybody who's doing really advanced stuff on sophisticated frameworks is welcome to try it out now and let us know now if there are any problems that remain</li> <li> 		How little of OSGi can I get away with?</li> </ul> 	Hooks <ul> <li> 		Many of the hooks - especially on services and models will continue to work, but won't have more power than in 6.2. They're prime candidates to be converted to an OSGi module as this will enable them to tap into a lot more extension points in Liferay 7.</li> <li> 		Struts Action Hooks probably need changes - while they still work, most of the underlying actions have been reimplemented without Struts \o/, so possible overloads in Struts actions won't be taken into account for the new implementation. 		<ul> <li> 				(most likely: You need to convert to an MVC Command, injected as an OSGi module. There are samples available)</li> </ul> </li> <li> 		Liferay 7 has a lot more extension points than prior versions. The documentation is being made available on <a href="https://dev.liferay.com" rel="nofollow" target="_blank">dev.liferay.com</a> - obviously this is still work in progress, but is scheduled to be there until release.</li> <li> 		How can <a href="https://www.youtube.com/watch?v=CfHqAUz3I1Y" rel="nofollow" target="_blank">IDE</a> and other tools help identifying which extension points are in use? And how to make lots of friends within the Liferay Community</li> <li> 		Overriding Language Keys is quite simple - choose "global" or "per portlet" - those are the two available scopes that a translation can live in. 		<ul> <li> 				For migration you might have to decide which scope your changes should go into.</li> <li> 				Encoding still is done in UTF-8</li> </ul> </li> <li> 		JSP-Hooks: The elephant in the room: Seems to be very popular, but always has aimed at the implementation rather than to an API. 		<ul> <li> 				As drastic UI changes happened in Liferay, these implementation need to be implemented on the new infrastructure, leveraging new techniquest (e.g. Lexicon). Also, most of the functionality has been moved into modules - JSP-Hooks only affected the core jsps...</li> <li> 				New options: JSPs can be deployed as proper OSGi bundles.</li> <li> 				There's still <a href="https://www.liferay.com/web/olaf.kock/blog/-/blogs/overriding-jsps-from-multiple-hooks-promising-the-cure" rel="nofollow" target="_blank">danger</a> because technically the implementation is unchanged compared to earlier versions</li> <li> 				New fragment modules enable you to override JSPs in any portlet - not only core ones. 				But you shouldn't limit yourself to JSP-overrides: There are more ways to change Liferay's UI, e.g. 				<ul> <li> 						replace the render-phase of a portlet through a portlet filter.</li> <li> 						A new "dynamic include" API to inject extension points at very specific places - e.g. at those UIs commonly targetted by overrides. (let us know which are missing) 						Application Adapters</li> </ul> </li> </ul> </li> </ul> 	Ext <ul> <li> 		Ext Plugins work just like before (in core). But most likely, the implementation has changed anyway, so that you need to make sure your code is still valid for the current version - but that's what you expected when you started writing that ext anyways, right?</li> <li> 		Of course you'll have to check if your changes still are contained in Liferay core. If they're extracted to a module, ext won't be yours any more (for these changes) 		Ideally, ext will be the easiest plugin, as it probably will be a lot smaller than before.</li> </ul> We haven't covered all possible questions and are planning a "Listener Questions" episode. Please ask your questions in the comments to the blog article for this episode to get them answered in the next episode with Ray.

RL052 Raymond Augé - Upgrading your 6.x plugins to 7.0

	Another Devcon "private" session - I missed his presentations, but got the summary right when he was done: Ray Augé took the time to answer all sorts of questions about the Modularization in Liferay 7. In fact, he answered so many questions that we made it a 2-episode recording. This week it's about the motivation for modularization: What problem does it solve? Next week will be more technical, telling you about the implications of the updated architecture to your code. 	As we recorded this on site at Devcon, you'll hear more background noise than usual - As usual, Auphonic did their best to clean the recording, and they did a great job. 	Here are some of the topics that we talked about:  		OSGi in Liferay 6.2 vs Liferay 7.0 		Modularization of Liferay 7.0 		Surprisingly (not!), modularization is not yet fully done, but it came a lot further than expected initially 		How much do you have to re-learn to build plugins for Liferay 7 		James: Community Roadmap Talk from Devcon (note: Ray also had several presentations at Devcon, you'll find his recordings there as well) 		Now everybody should be able to work the same way: Internally in Liferay's core as well as externally, in the plugins. 		Ant vs Maven vs others? What's the story with Liferay's supported Build environments? More energy will go into build tools other than the SDK 		Of course we cover a release date :) I'm getting a very rough one from Ray :)

Another Devcon "private" session - I missed his presentations, but got the summary right when he was done: <a href="https://www.liferay.com/web/raymond.auge" rel="nofollow" target="_blank">Ray Augé</a> took the time to answer all sorts of questions about the Modularization in Liferay 7. In fact, he answered so many questions that we made it a 2-episode recording. This week it's about the motivation for modularization: What problem does it solve? Next week will be more technical, telling you about the implications of the updated architecture to your code. 	As we recorded this on site at Devcon, you'll hear more background noise than usual - As usual, <a href="https://auphonic.com" rel="nofollow" target="_blank">Auphonic</a> did their best to clean the recording, and they did a great job. 	Here are some of the topics that we talked about: <ul> <li> 		OSGi in Liferay 6.2 vs Liferay 7.0</li> <li> 		Modularization of Liferay 7.0</li> <li> 		Surprisingly (not!), modularization is not yet fully done, but it came a lot further than expected initially</li> <li> 		How much do you have to re-learn to build plugins for Liferay 7</li> <li> 		James: Community Roadmap Talk from <a href="https://www.liferay.com/web/events2015/devcon/recap" rel="nofollow" target="_blank">Devcon</a> (note: Ray also had several presentations at Devcon, you'll find his recordings there as well)</li> <li> 		Now everybody should be able to work the same way: Internally in Liferay's core as well as externally, in the plugins.</li> <li> 		Ant vs Maven vs others? What's the story with Liferay's supported Build environments? More energy will go into build tools other than the SDK</li> <li> 		Of course we cover a release date :) I'm getting a very rough one from Ray :)</li></ul>

RL051 Raymond Augé - Motivation for Modularization

	Episode 4 of Radio Liferay is out. I'm speaking with Raymond Augé,  Sr. Software Architect at Liferay 	We spoke about these topics - and probably more:  		Internet coverage in Northern Ontario  Forums, IRC, Blog 		The beauty of XML and XSLT (in 2004) 		Bits of Liferay's history since 2004, e.g. the Sourceforge Mailinglist 		Some Features Ray has been involved in: WCMS, Permissions, Document Repositories, Asset API, Service Builder, Staging, Search - basically most of what's somehow related to WCM. 		The enjoyment of sharing information. Not disseminating information is counterproductive. (At this place I'd like to place a completely unrelated shoutout to JT - you know what for ;-) ) 		the benefits of keeping hands away from UI code. 		(Learning english in this episode consists of my "inadvertently" stumbling across my tongue) 		Feature talk: The new staging in 6.1, "site variations", how work on it was done. 		The use of the different templating languages: Velocity, Freemarker, XSLT 		WebContent and Templates can partly replace portlet &amp; plugin development.  Documented on Ray's Blogpost Advanced Web Content Example with Ajax and Liferay Live presentation 		OSGi, in Ray's Blog and on github

Episode 4 of Radio Liferay is out. I'm speaking with <a href="https://www.liferay.com/web/raymond.auge/profile" rel="nofollow" target="_blank">Raymond Augé</a>,  Sr. Software Architect at Liferay 	We spoke about these topics - and probably more: <ul> <li> 		Internet coverage in Northern Ontario</li> <li> <a href="https://www.liferay.com/web/guest/community/forums" rel="nofollow" target="_blank">Forums</a>, <a href="http://webchat.freenode.net/?channels=liferay&amp;uio=d4" rel="nofollow" target="_blank">IRC</a>, <a href="https://www.liferay.com/de/web/raymond.auge/blog" rel="nofollow" target="_blank">Blog</a></li> <li> 		The beauty of XML and XSLT (in 2004)</li> <li> 		Bits of Liferay's history since 2004, e.g. the Sourceforge Mailinglist</li> <li> 		Some Features Ray has been involved in: WCMS, Permissions, Document Repositories, Asset API, Service Builder, Staging, Search - basically most of what's somehow related to WCM.</li> <li> 		The enjoyment of sharing information. Not disseminating information is counterproductive. (At this place I'd like to place a completely unrelated shoutout to <a href="https://www.liferay.com/web/justin.tanaka/profile" rel="nofollow" target="_blank">JT</a> - you know what for ;-) )</li> <li> 		the benefits of keeping hands away from UI code.</li> <li> 		(Learning english in this episode consists of my "inadvertently" stumbling across my tongue)</li> <li> 		Feature talk: The new staging in 6.1, "site variations", how work on it was done.</li> <li> 		The use of the different templating languages: Velocity, Freemarker, XSLT</li> <li> 		WebContent and Templates can partly replace portlet &amp; plugin development.  Documented on Ray's Blogpost<a href="https://www.liferay.com/web/raymond.auge/blog/-/blogs/advanced-web-content-example-with-ajax" rel="nofollow" target="_blank"> Advanced Web Content Example with Ajax</a> and <a href="https://www.liferay.com/video?title=video-web-event-web-content" rel="nofollow" target="_blank">Liferay Live</a> presentation</li> <li> 		OSGi, in <a href="https://www.liferay.com/web/raymond.auge/blog/-/blogs/10660399" rel="nofollow" target="_blank">Ray's Blog</a> and on <a href="https://github.com/rotty3000/liferay-portal/tree/OSGi" rel="nofollow" target="_blank">github</a></li></ul>