Liferay Faces Project News - April 2016

Neil Griffin
Neil Griffin
Less Than a Minute Read
The Liferay Faces team has been working hard on a variety of tasks, including:
  • Support for JSF OSGi portlets with Liferay Portal 7.0 CE
  • Maturing the source in our New Git Repositories
  • Finalizing our New Version Scheme
  • Making Liferay Faces Alloy compatible with AlloyUI 3.0
  • Developing the new Liferay Faces Metal component suite based on Metal.js
  • Participating on JSR 362: Portlet Specification 3.0
  • Leading JSR 378: Portlet 3.0 Bridge for JSF 2.2
With the recent release of Liferay Portal 7.0 CE GA1, I thought it would be good to provide details of our plans for supporting JSF OSGi portlets. 
 

Packaging / Web Application Bundle

UPDATE, April 28, 2016: The original contents of this section have been incorporated into the official Packaging a JSF Application tutorial.

Dependencies

UPDATE, Sept 2, 2016: Removed the snapshot repository info and the -SNAPSHOT qualifier from the dependencies section below.

UPDATE, May 13, 2016: The following dependency groupIds were shortened to simply "com.liferay.faces" and the artifactIds were renamed according to the OSGi File Naming Convention.

<dependencies>
  <dependency>
    <groupId>com.liferay.faces</groupId>
    <artifactId>com.liferay.faces.alloy</artifactId>
    <version>3.0.0</version>
  </dependency>
  <dependency>
    <groupId>com.liferay.faces</groupId>
    <artifactId>com.liferay.faces.bridge.impl</artifactId>
    <version>4.0.0</version>
  </dependency>
  <dependency>
    <groupId>com.liferay.faces</groupId>
    <artifactId>com.liferay.faces.bridge.ext</artifactId>
    <version>5.0.0</version>
  </dependency>
  <dependency>
    <groupId>com.liferay.faces</groupId>
    <artifactId>com.liferay.faces.portal</artifactId>
    <version>3.0.0</version>
  </dependency>
  <dependency>
    <groupId>com.sun.faces</groupId>
    <artifactId>jsf-impl</artifactId>
    <version>2.2.13</version>
  </dependency>
</dependencies>

For more information, refer to the new Liferay Faces Version Scheme.

Release Schedule / Examples / Demos

Follow @liferayfaces in order to be kept up-to-date as to the release schedule for Liferay Portal 7.0 CE support in Liferay Faces as well as forthcoming examples and demos.

Page Comments
thumbnail
Peter Mesotten
9 Years Ago
Hi Neil,

Thanks for the info. I think this is good news for developers that considered JSF as the most straight-forward and best supported framework for creating portlets in Liferay.

Just a few questions:
1. As approach 1 bypasses the auto-deploy process, does it mean that you have to expand the WAR in the webapps yourself? Or can we still just copy the WAR over to the deploy folder and is it expanded by Liferay (but not enhanced)?
2. Suppose we have a bunch of JSF portlets that are all want to use some custom built OSGi bundles and their services. Is this possible in both approaches? From what I understand, this will only work in approach 1?
3. Same for Liferay services. Can Liferay services be injected into our JSF portlet in both approaches?
4. One of the drawbacks of JSF portlets in Liferay < 7.0 was the large footprint in terms of the libraries that needed to be added to each and every portlet again. With OSGi in mind, I was hoping to be able to abstract the JSF layer (meaning the different JSF libraries, the faces bridge JARs, possibly some PrimeFaces libs, ...) away in a reusable OSGi module that could then be reused across all the different portlets. Which would also make it very straightforward to e.g. upgrade to a newer JSF version. Is something like this possible or will it be possible in the near future? Or are there alternative options that have a similar result?

Thank you for the effort you're putting into keeping JSF support up to speed with the latest developments in Liferay!
Please sign in to reply.
thumbnail
Neil Griffin Peter Mesotten
9 Years Ago - Edited
Hi Peter,

On behalf of the Liferay Faces team, thanks so much for the kind words! emoticon

A1) With Liferay Portal 7.0 CE, copying any artifact to $LIFERAY_HOME/deploy simply causes the artifact to be moved to the appropriate sub-directory under $LIFERAY_HOME/osgi. For example, copying a WAR artifact to $LIFERAY_HOME/deploy will cause the artifact to be moved to $LIFERAY_HOME/osgi/war. You might want to consider copying WAR artifacts directly to $LIFERAY_HOME/osgi/war in order to avoid incurring the cost of the move. Since approach #1 bypasses the auto-deploy process, you must manually add <servlet>, <listener>, etc. to the src/main/webapp/WEB-INF/web.xml descriptor. By having a ready-to-deploy web.xml in the source of your project, there is no need to expand the WAR yourself. When using approach #2, you can override the values of the following properties in order to see the results of the WAB Generator:

#
# Set this to true to store the generated WABs.
#
module.framework.web.generator.generated.wabs.store=false

#
# Set the directory where the generated WABs will be stored. This property
# is not used unless the property
# "module.framework.web.generator.generated.wabs.store" is set to true.
#
module.framework.web.generator.generated.wabs.store.dir=${module.framework.base.dir}/wabs

A2) Since approach #1 and #2 both result in the deployment of WABs (which are true OSGi modules), both approaches can utilize custom-built OSGi services.

A3) You can still call the traditional Liferay *ServiceUtil static methods in order to utilize Liferay services in your WABs, but please avoid using them if at all possible. Instead, use the OSGi services because there might likely be a deprecation process for the *ServiceUtil classes.

A4) For Liferay Portal 7.0 CE, JSF WARs must embed dependencies such as jsf-api.jar, jsf-impl.jar, weld-servlet.jar, primefaces.jar etc. in WEB-INF/lib. This is true for all app servers, including ones like WildFly that ship with a version of Mojarra and Weld. This is because Liferay/OSGi is in control of the ClassLoader and does not delegate class loading responsibility to the app server. However, we do hope to develop an OSGi "extender" for JSF that might make it possible to deploy these dependencies as separate OSGi modules. Since we are still gathering requirements for the extender, we can't provide a completion date. For now, you should assume that embedding dependencies in WEB-INF/lib is the only available option.

Kind Regards,

Neil
Please sign in to reply.
Benji Mommen
9 Years Ago
Hi Neil,

Thanks for your useful blog post!

I was experimenting with the provided dependencies and I think the repository url should be:

https://oss.sonatype.org/content/groups/public/

instead of:

https://oss.sonatype.org/content/repositories/snapshots/com/liferay/faces/
Please sign in to reply.
thumbnail
Neil Griffin Benji Mommen
9 Years Ago
Thanks Benji. I'm glad you found the information to be useful. Also, I updated the content of the blog with a link to the new "Packaging a JSF Application" tutorial and updated the snapshot repository URL.
Please sign in to reply.
efrain romero
9 Years Ago
Hi, im totally unable to find anyware this:

org.apache.portals.pluto:portlet-api:jar:3.0-SNAPSHOT

any tips?
Please sign in to reply.
thumbnail
Neil Griffin efrain romero
9 Years Ago
Kyle Stiemann posted some instructions here: https://github.com/liferay/liferay-faces-bridge-impl/issues/108

The 5.x branch is for Portlet 3.0, which is why you ran into the missing dependency. Liferay Portal doesn't yet support Portlet 3.0 since JSR 362 hasn't reached "Final" status.
Please sign in to reply.

Related Assets...

No Results Found

More Blog Entries...

Ben Turner
October 21, 2025
Michael Wall
October 14, 2025
YOGESH CHANDRA
October 08, 2025