Radio Liferay Episode 52: Ray Auge - Modularization II - Upgrading your Plugins

  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.

Follow @RadioLiferay, @rotty3000 (Ray) and @olafk (me) on twitter.

You'll find this episode - and make sure that you don't miss any of the future episodes - by subscribing to  http://feeds.feedburner.com/RadioLiferay. You can also subscribe on itunes.: Just search for "Radio Liferay" or just "Liferay" in the podcast directory. If you like this, make sure to write a review for the podcast directory of your choice - or find everything about Radio Liferay on liferay.com/radio.

Or just download the MP3 here:

download audio file

Blogs
To get the visual while listening: https://www.facebook.com/liferay/photos/a.10153250954798108.1073741866.45119213107/10153250960128108/?type=3&theater
Do you have a module that is responsible for the whole URL parsing + creation + rewriting + etc so that I am able to completely change how URLs look like in LR?
E.g.:
- URLs currently have the format:
http://<hostname>/<language>/web/<group-friendly-url>/<layout-friendly-url>
- but my customer wants to have them in a format like
http://<hostname>/<group-friendly-url>/<language>/<layout-friendly-url>
or
etc