Recent Bloggers

Olaf Kock

Staff
119 Publications
9 décembre 2016

Milen Dyankov

Staff
5 Publications
9 décembre 2016

gulnaaz Shaik

2 Publications
8 décembre 2016

Javeed Chida

15 Publications
8 décembre 2016

Neeraj Gautam

Staff
1 Publications
7 décembre 2016

David H Nebinger

32 Publications
6 décembre 2016

Vikash Chandrol

1 Publications
2 décembre 2016

Eduardo P. Garcia

Staff
10 Publications
2 décembre 2016

James Hinkey

Staff
6 Publications
29 novembre 2016

Adrian Johnson

Staff
1 Publications
22 novembre 2016

Announcement: Support for JSF in Liferay Portal 7.0 / DXP

Company Blogs 2 septembre 2016 Par Neil Griffin Staff

On August 29, 2016 Liferay released a new version of Liferay Faces based on the new Liferay Faces Version Scheme. Because of our efforts towards greater modularity, many of the Liferay Faces artifacts now have independent release schedules.

This new release includes support for JSF in Liferay Portal 7.0 / DXP as well as updated support for Liferay Portal 6.2.

Downloads

The www.liferayfaces.org site has been updated with a new portlet on the home page that enables developers to choose their desired combination of Liferay Portal + JSF + Component Suite in order to find project templates (archetypes), and determine dependency configuration.

Component Showcases

Visit www.liferayfaces.org to test-drive our component showcases:

Component Suites

This new release has been tested with the following component suites:

  • Liferay Faces Alloy 3.0.0
  • PrimeFaces 6.0
  • ICEfaces 4.1.1
  • RichFaces 4.5.17.Final

Updated Demos

Visit the demos page in order to find links to updated demo portlets that you can download and try in your Liferay Portal 7.0 / DXP environment.

Related Blogs

The following blog posts are related to this new release and provide important details about the Liferay Faces project:

Thank You

The Liferay Faces team has worked diligently for more than a year in order to make this release possible. Many thanks to Vernon Singleton, Kyle Stiemann, Phil White, Juan Gonzalez, and Cody Hoag for all their hard work and dedication. Also thanks to the members of the Liferay Portal Core Engineering team (Ray Auge, Miguel Pastor, Carlos Sierra, et al.) for all their help in making JSF support a reality in Liferay Portal 7 / DXP. Finally, thanks to Brian Chan and Jorge Ferrer for their leadership and support for our team!

New Maven Archetypes for JSF Portlets

Company Blogs 6 juillet 2016 Par Neil Griffin Staff

UPDATE: September 2, 2016 - Visit www.liferayfaces.org for a convenient web page that helps you determine your archetype:generate command and/or required dependencies.

The Liferay Faces team is working on production support for JSF portlets in Liferay Portal 7.0 and Liferay DXP. As part of this effort, we have developed some archetypes for use with Maven 3.

For a plain JSF portlet, type the following at the command line:
mvn archetype:generate \
  -DgroupId=com.mycompany \
  -DartifactId=com.mycompany.my.jsf.portlet \
  -DarchetypeGroupId=com.liferay.faces.archetype \
  -DarchetypeArtifactId=com.liferay.faces.archetype.jsf.portlet \
  -DarchetypeVersion=5.0.0 \
  -DinteractiveMode=false
For a PrimeFaces portlet, type the following:
mvn archetype:generate \
  -DgroupId=com.mycompany \
  -DartifactId=com.mycompany.my.primefaces.portlet \
  -DarchetypeGroupId=com.liferay.faces.archetype \
  -DarchetypeArtifactId=com.liferay.faces.archetype.primefaces.portlet \
  -DarchetypeVersion=5.0.0 \
  -DinteractiveMode=false
For a Liferay Faces Alloy portlet, type the following:
mvn archetype:generate \
  -DgroupId=com.mycompany \
  -DartifactId=com.mycompany.my.alloy.portlet \
  -DarchetypeGroupId=com.liferay.faces.archetype \
  -DarchetypeArtifactId=com.liferay.faces.archetype.alloy.portlet \
  -DarchetypeVersion=5.0.0 \
  -DinteractiveMode=false
For an ICEfaces portlet, type the following:
mvn archetype:generate \
  -DgroupId=com.mycompany \
  -DartifactId=com.mycompany.my.icefaces.portlet \
  -DarchetypeGroupId=com.liferay.faces.archetype \
  -DarchetypeArtifactId=com.liferay.faces.archetype.icefaces.portlet \
  -DarchetypeVersion=5.0.0 \
  -DinteractiveMode=false
For a RichFaces portlet, type the following:
mvn archetype:generate \
  -DgroupId=com.mycompany \
  -DartifactId=com.mycompany.my.richfaces.portlet \
  -DarchetypeGroupId=com.liferay.faces.archetype \
  -DarchetypeArtifactId=com.liferay.faces.archetype.richfaces.portlet \
  -DarchetypeVersion=5.0.0 \
  -DinteractiveMode=false

Liferay IDE / Liferay Developer Studio

If you are developing your JSF portlets with Eclipse for Java EE Developers, you can install the Liferay IDE pluginsOtherwise, if you are developing with Liferay Developer Studio, the plugins are installed by default.
After your project is created with the mvn archetype:generate command, you can import the project into Eclipse using the following steps:
1. Click File -> Import ...
2. Expand the "Maven" category
3. Click on "Existing Maven Projects" and click Next
4. Enter the full directory path to your newly created project
5. Click Finish
 
In order to deploy the portlet, simply drag the project to the "Liferay 7" or "Liferay DXP" server in the Servers pane.
 

OSGi File Naming Convention for Liferay Faces Artifacts

Company Blogs 13 mai 2016 Par Neil Griffin Staff

The Liferay Faces team is moving closer towards the goal of releasing a JSF portlet bridge (and associated demos) for use with Liferay Portal 7.0 CE.

Since this new version of the portal utilizes OSGi to achieve modularity, the portal's dependency artifact filenames follow the OSGi file naming convention using Bundle-SymbolicName. For example: The old portal-service.jar artifact has been renamed to com.liferay.portal.kernel.jar due to the following line in META-INF/MANIFEST.MF:

Bundle-SymbolicName: com.liferay.portal.kernel
This type of convention effectively prepends the groupId to the artifact name. Recent examples in Java EE that follow a similar type of convention include javax.servlet-api.jar and javax.faces-api.jar.
 
Although the Liferay Faces artifacts are currently designed to be embedded dependencies (inside the WEB-INF/lib directory of a WAR), we have adopted the aforementioned file naming convention in order to be consistent with the rest of the company. It will also help to guide us towards the goal of having the Liferay Faces dependency artifacts to be separately deployable OSGi bundles. For more information, see FACES-2681.
 
Schedule:
Here are some examples of what you can expect:
 
Liferay Faces Dependency Artifact Filenames
(groupId: com.liferay.faces)
Old Naming Convention New Naming Convention
liferay-faces-alloy.jar com.liferay.faces.alloy.jar
liferay-faces-bridge-api.jar com.liferay.faces.bridge.api.jar
liferay-faces-bridge-impl.jar com.liferay.faces.bridge.impl.jar
liferay-faces-metal.jar com.liferay.faces.metal.jar
liferay-faces-portal.jar com.liferay.faces.portal.jar
liferay-faces-util.jar com.liferay.faces.util.jar

In addition, we are renaming our demo portlets:

Liferay Faces Demo Artifact Filenames
(groupId: com.liferay.faces.demo)

Old Naming Convention New Naming Convention
alloy3-portlet.war com.liferay.faces.demo.alloy.applicant.portlet.war
icefaces4-portlet.war com.liferay.faces.demo.icefaces.applicant.portlet.war
jsf2-portlet.war com.liferay.faces.demo.jsf.applicant.portlet.war
jsf2-cdi-portlet.war com.liferay.faces.demo.jsf.cdi.applicant.portlet.war
jsf2-export-pdf-portlet.war com.liferay.faces.demo.jsf.export.pdf.portlet.war
jsf2-ipc-pub-render-params-portlet.war com.liferay.faces.demo.jsf.ipc.pub.render.params.portlet.war
jsf2-ipc-events-bookings-portlet.war com.liferay.faces.demo.jsf.ipc.events.bookings.portlet.war
jsf2-ipc-events-customers-portlet.war com.liferay.faces.demo.jsf.ipc.events.customers.portlet.war
primefaces5-portlet.war com.liferay.faces.demo.primefaces.applicant.portlet.war
primefaces5-users-portlet.war com.liferay.faces.demo.primefaces.users.portlet.war
richfaces4-portlet.war com.liferay.faces.demo.richfaces.applicant.portlet.war

Finally, we have updated the official Liferay documentation titled Liferay Faces Version Scheme for Releases After Liferay Faces GA6.

Liferay Faces Project News - April 2016

Company Blogs 6 avril 2016 Par Neil Griffin Staff

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.

New Liferay Faces Version Scheme

Company Blogs 31 mars 2016 Par Neil Griffin Staff

In a blog post from September 2015 titled New Git Repositories for Liferay Faces I mentioned that there would be a new version scheme corresponding to these new repositories.

I'm pleased to announce that Cody Hoag from the Liferay Documentation Team has published an update to the official Liferay documentation titled "Understanding the Liferay Faces Version Scheme" with a new section titled Liferay Faces Version Scheme for Releases After Liferay Faces GA6.

Please note that the new version scheme has not been finalized and that it may undergo changes prior to our support for Liferay Portal 7.0 CE.

New Git Repositories for Liferay Faces

Company Blogs 25 septembre 2015 Par Neil Griffin Staff

Multi-Module Projects

Developers that are familiar with the version scheme of the Spring Framework will notice that each module has the same version number. For example:

  • spring-beans-4.2.1.RELEASE.jar
  • spring-context-4.2.1.RELEASE.jar
  • spring-core-4.2.1.RELEASE.jar
  • ... etc ...

This is because the Spring Framework is configured as a multi-module project. This concept isn't necessarily tied to a particular build tool, but I think that it is fair to say that it is a feature of Maven that is used quite often by developers.

Similar to the Spring Framework, the Liferay Faces project was originally built as a multi-module project in which each artifact had the same version number. For example:

  • liferay-faces-alloy-4.2.5-ga6.jar
  • liferay-faces-bridge-api-4.2.5-ga6.jar
  • liferay-faces-bridge-impl-4.2.5-ga6.jar
  • liferay-faces-portal-4.2.5-ga6.jar
  • liferay-faces-util-4.2.5-ga6.jar

This was achieved using a parent POM like the following:

liferay-faces/pom.xml

<project ...>
    <version>4.2.5-ga6</version>
    ...
    <modules>
        <module>alloy</module>
        <module>bridge-api</module>
        <module>bridge-impl</module>
        <module>portal</module>
        <module>util</module>
    </modules>
    ...
</project>

I think that there are development scenarios in which it might make sense to create a multi-module project. But as with most design decisions, there are typically benefits and drawbacks.

Benefits of a Multi-Module Project

The main benefit of a multi-module project is convenience:

  • Convenient Development: We used Maven to layout a multi-module project structure which provided a convenient development environment. When we first started the Liferay Faces project, we had only a handful of jar/war modules and a single master branch. As we added additional jar modules and demo war modules, it was easy to expand the development environment.
  • Convenient Testing: Since all of our modules were located in the same multi-module project structure, it was convenient to add Selenium tests to that same structure.
  • Convenient Releases: Performing releases was easy thanks to the maven-release-plugin.
  • Convenient Deployment: It was also convenient for our customers and community since they could specify the same version number for each Liferay Faces module in their pom.xml or ivy.xml descriptors.
  • Convenient Version Control: We were able to use a single liferay-faces Git repository for managing the source code.

Drawbacks of a Multi-Module Project

As we added support for new versions of Liferay Portal and new versions of JSF, our single Git repository ended up with seven different branches. In order for developers to know which version corresponded to their environment, they had to read the official documentation for Understanding the Liferay Faces Version Scheme.


As an illustration of the drawback of having all modules on the same release schedule, consider a team that is running a race hand-in-hand (or arm-in-arm). The team can only go as fast as the slowest runner.

Although the multi-module project structure was convenient, it became increasingly difficult to get releases done in a timely manner. For our GA6 release, we added lots of new components to Liferay Faces Alloy (as shown in the Liferay Faces Showcase). But since liferay-faces-alloy.jar had the same version number as all the other modules, we were not able to release simple fixes for other modules since all of the modules had to be completed and released on the same schedule.

In order to compensate for this drawback it was necessary to release a series of patches for Liferay Faces GA5 in the form of jar modules that were deployed alongside our GA5 modules.

An Extreme Alternative

If the benefits of a multi-module project (within a single Git repository) do not outweigh the drawbacks, then an extreme alternative would be to have each module in its own Git repository. This provides the ability to independently version each module and to have each module on a separate release schedule.

Compromise for Liferay Faces

In order for us to support our customers and community in a more agile manner, it is necessary to independently version each library (jar) module. However, each demo module (like jsf2-portlet.war) does not need to be independently versioned. This will allow us to support separate release schedules so that we won't have to rely so heavily on patch jars. As a result, we split the single liferay-faces Git repository into multiple Git repositories.

New Git Repositories

Git Repository Description

liferay-faces-alloy

Multi-module Maven project structure that contains the liferay-faces-alloy.jar library module, liferay-faces-alloy-reslib.jar, and associated demo war modules. 

liferay-faces-bridge-api

Single-module Maven project structure that contains the Bridge API jar for JSR 378.

liferay-faces-bridge-ext

Single-module Maven project structure that extends Liferay Faces Bridge to support Liferay Portal.

liferay-faces-bridge-impl

Multi-module Maven project structure that contains the Reference Implementation jar for JSR 378, the Bridge TCK, and associated demo war modules.
liferay-faces-metal Currently a placeholder for an upcoming JSF component suite based on Metal.js for use with Liferay 7.0.

liferay-faces-maven

Multi-module Maven project structure for Maven plugins. 
liferay-faces-portal Multi-module Maven project structure that contains the liferay-faces-portal.jar library module as well as associated demo war modules.

liferay-faces-util

Single-module Maven project structure that contains the liferay-faces-util.jar library module.

New Dependency Tree

One of the benefits of splitting up our single Git repository into separate Git repositories is that the dependencies between modules are more clearly seen, as shown in the following diagram:

(click the preview to see a larger version)

Conclusion

Although the multi-module project structure was convenient in many ways, the benefits did not outweigh the drawbacks. We now have the ability to independently version each jar module in order to support separate release schedules. In addition, we will be able to better adhere to the rules of Semantic Versioning.

[UPDATE: 2016/03/31, see the follow-up blog post titled New Liferay Faces Version Scheme].

The Decisive Moment in the History of JSF

Company Blogs 18 septembre 2015 Par Neil Griffin Staff

JavaServer™ Faces (JSF) is one of the standards developed under the Java Community Process (JCP) and was first introduced with Java EE 1.4. The first version of JSF had its share of proponents, but also had its share of criticism. Over the years it has been continuously improved by JCP Expert Groups (EGs) and extended by 3rd-party libraries like PrimeFaces, ICEfaces, RichFaces, OmniFaces, BootsFaces, AngularFaces, ADF Faces, OpenFaces, MyFaces Tomahawk, MyFaces Trinidad, and Liferay Faces.

In a recent poll of over 1,000 respondents, JSF ranked as the most popular webapp framework (just ahead of Spring MVC). Over the years I've asked myself the question -- What is the main reason for the longevity of JSF? Also, why do so many developers continue to use JSF in new projects? Here are some possible reasons:

  • The expertise of Amy Fowler in bringing Swing-like ideas to JSF in the web tier?
  • The leadership of Ed Burns as a Spec Lead since the very beginning?
  • The helpful answers by EG members Bauke Scholtz (a.k.a BalusC) and Arjan Tijms at StackOverflow?
  • The variety of JSF books published over the years?
  • The industry backing of Oracle/Sun, RedHat/JBoss, IBM, PrimeTek, ICEsoft, and Liferay?
  • The tooling provided by IDEs like NetBeans, Eclipse, and IntelliJ IDEA?
  • The advocacy by EG member Kito Mann of JSF Central?
  • The open source nature of Mojarra, MyFaces Core, and the many JSF component suites?
  • The talents of developers like Ryan Lubke and Manfred Riem of Mojarra?
  • The commitment of Martin Marinschek and Leonardo Uribe of Irian to MyFaces?
  • The integration efforts made by JBoss developers like Stan Silvert, Gavin King, Pete Muir, Wesley Hales, Lincoln Baxter III, and Ken Finnigan?
  • The contributions made by developers like Adam Winer and Andy Schwartz of ADF Faces?
  • The solutions by developers like Ken Pausen of JSF Templating and Jacob Hookom of Facelets?
  • The creativity of developers like Ted Goddard, Deryk Sinotte, and Mark Collette at ICEsoft?
  • The ingenuity of developers like Alexander Smirnov, Jay Balunas, Ilya Shaikovsy, and Brian Leathem of RichFaces?
  • The innovation by developers like Çağatay Çivici, Mert Çalışkan, and Thomas Andraschko of PrimeFaces?

Perhaps all of these reasons combined may be the answer.

But I think there is a decisive moment in the history of JSF that is the primary reason why the technology is still popular in new projects today. Here is a brief chronological list of some possibilities:

1. 11 Mar, 2004 JSF 1.0 is released under JSR 127, Spec Leads: Craig McClanahan and Ed Burns.
2. 27 May, 2004 JSF 1.1 is released under JSR 127, Spec Leads: Craig McClanahan and Ed Burns.
3. 09 June, 2004 Hans Bergsten (expert group member of JSR 127/252) publishes an article titled Improving JSF by Dumping JSP claiming that a view technology other than JSP would be necessary to fully take advantage of JSF.
4. 28 June, 2004 Ed Burns posts a blog announcement that Sun Microsystems has released the source code of the JSF RI (later to be named Mojarra).
5. 13 Apr, 2005 Apache MyFaces 1.0.9 is released as an alternative implementation to the JSF RI.
6. 17 Aug, 2005 Jacob Hookom (member of the JSR 252 EG) publishes the first of a three-part series of articles titled Inside Facelets on JSF Central which describes the Facelets templating language as an alternative view technology for JSF.
7. 21 Apr, 2006 Ken Paulsen makes one of the first CVS commits to the JSF Templating project.
8. 11 May, 2006 JSF 1.2 is released under JSR 252, Spec Leads: Ed Burns and Roger Kitain.
9. 14 Nov, 2006 ICEsoft announces in a press release that ICEfaces is made available under an open source license.
10. 29 Mar, 2007 Red Hat and Exadel announce a partnership that makes RichFaces available under an open source license.
11. 29 Oct, 2008 Çağatay Çivici makes the first commit to PrimeFaces.
12. 01 Jul, 2009 JSF 2.0 is released under JSR 314, Spec Leads: Ed Burns and Roger Kitain.
13. 22 Nov, 2010 JSF 2.1 is released under JSR 314, Spec Leads: Ed Burns and Roger Kitain.
14. 13 Jan, 2011 Portlet 2.0 Bridge for JSF 1.2 is released under JSR 329, Spec Lead: Mike Freedman.
15. 21 May, 2013 JSF 2.2 is released under JSR 344, Spec Lead: Ed Burns.
16. 09 Sep, 2014 Ballot to begin work for JSF 2.3 is approved under JSR 372 with Ed Burns and Manfred Riem as co-spec-leads.
17. 21 Jul, 2015 Ballot to begin work for Portlet 3.0 Bridge for JSF 2.2 is approved under JSR 378.

Conclusion

Which event do I think was the decisive moment in the history of JSF?

#6: 17 Aug, 2005: Jacob Hookom publishes the first of a three-part series of articles titled Inside Facelets on JSF Central.

Why do I think that is the case? Well as Rick Hightower once wrote: "Facelets fits JSF like a glove." And as Gavin King once said in an interview: "I think Facelets is by far the best templating engine I have ever worked with."

It is my opinion that the widespread usage and adoption of JSF can likely be traced back to Jacob's article at JSF Central, which led to the widespread usage of jsf-facelets.jar in JSF 1.2 webapps and the eventual inclusion of Facelets in the JSF 2.0 standard under JSR 314.

I would like to thank everyone mentioned in this article, everyone who has worked on the JSF EGs over the years, as well as the Faces of JSF for their dedication and hard work.

Liferay's Stewardship of JSR 378

Company Blogs 8 septembre 2015 Par Neil Griffin Staff

On August 3, 2015 the JCP Executive Committee approved the ballot for starting JSR 378: Portlet 3.0 Bridge for JavaServer™ Faces 2.2. This is the first time that Liferay will be leading a JSR and as the Spec Lead I will be heading up the stewardship role. Liferay will also be represented by Vernon Singleton, Juan Gonzalez, and Kyle Stiemann as members of the Expert Group.
 
First and foremost I would like to thank Michael Freedman for the work he did representing Oracle as the Spec Lead for JSR 329 (the predecessor of JSR 378). His mastery of the subject matter and his attention to detail are second-to-none, and I will be standing on the shoulders of a giant. I would also like to thank Ed Burns, Manfred Riem, and Ross Clewley of Oracle for their kindness in helping to make JSR 378 a reality.
 

Open Standards + Open Source = Confidence

Open standards like those from the JCP are important to Liferay's customers and community because they instill confidence in the staying power of a technology. Since the JCP expert groups do their work in an open manner, anyone can follow the progress of these technologies. In addition, many of the Reference Implementations (RIs) are developed as open source. Liferay Faces Bridge will be the RI for JSR 378 and will be made available under the Apache License, Version 2.0.
 
Over the years Liferay has served on JSR 362 (Portlet 3.0), JSR 372 (JSF 2.3), JSR 344 (JSF 2.2), JSR 314 (JSF 2.0/2.1), and JSR 286 (Portlet 2.0). By taking a leadership role with JSR 378 and developing the RI as open source, Liferay customers and community members can be confident that their technology investment in JSF portlets will be supported for years to come.
 
For the latest news and updates, follow @FacesBridgeSpec via Twitter.

Announcement: Liferay Faces 4.x / 3.x / 2.x GA6 Released

Company Blogs 12 août 2015 Par Neil Griffin Staff

On August 11, 2015 Liferay released the 6th General Availability (GA) version of Liferay Faces:

Liferay Faces 4.2.5-ga6 JSF 2.2 + Liferay Portal 6.2 *NEW* Release Notes (420 Issues) - PrimeFaces 5.2/4.0
- RichFaces 4.5.6
Liferay Faces 3.2.5-ga6 JSF 2.1 + Liferay Portal 6.2  Release Notes (398 Issues) - PrimeFaces 5.2/4.0/3.5
- ICEfaces 3.3
- RichFaces 4.5.6
Liferay Faces 3.1.5-ga6 JSF 2.1 + Liferay Portal 6.1 Release Notes (231 Issues) - PrimeFaces 5.2/4.0/3.5
- ICEfaces 3.3
- RichFaces 4.5.6
Liferay Faces 3.0.5-ga6 JSF 2.1 + Liferay Portal 6.0 Release Notes (217 Issues) - PrimeFaces 4.0/3.5
- ICEfaces 3.3
- RichFaces 4.5.6
Liferay Faces 3.0.5-legacy-ga6 JSF 2.1 + Liferay Portal 5.2 Release Notes (201 Issues) - ICEfaces 3.3
Liferay Faces 2.2.5-ga6 JSF 1.2 + Liferay Portal 6.2  Release Notes (173 Issues) - ICEfaces 1.8.2
Liferay Faces 2.1.5-ga6 JSF 1.2 + Liferay Portal 6.1 Release Notes (171 Issues) - ICEfaces 1.8.2

All-New JSF Component Suite

Liferay Faces 4.2.5-ga6 (JSF 2.2 + Liferay Portal 6.2) and 3.2.5-ga6 (JSF 2.1 + Liferay Portal 6.2) feature an all-new JSF component suite as shown in the Liferay Faces Showcase.

The Facelet component tags that are prefixed with the alloy: namespace utilize AlloyUI and are compatible with webapp and portlet environments.

The Facelet component tags that are prefixed with the bridge: and portlet: namespaces are compatible with portlet environments.

The Facelet component tags that are prefixed with the portal: namespace are compatible with Liferay portlet environments.

For more information about the new component suite, see Juan Gonzalez' blog post titled New Liferay Faces release - Portal components and Vernon Singleton's blog post titled New Liferay Faces release - The alloy:accordion component.

Third Party Component Suite Compatibility

  • PrimeFaces 5.2: Check out the new primefaces5-portlet and primefaces5-users-portlet demos
  • ICEfaces 4.0: Due to ICE-10335ICE-10392, and ICE-10393 ICEfaces 4.0 is unsupported at this time. Developers can still use ICEfaces 3.1 with JSF 2.1 via Liferay Faces 3.2.5-ga6.
  • RichFaces 4.5: The richfaces4-portlet demo has been upgrade to RichFaces 4.5.6.Final.

Support For JSF 2.2 (Tomcat + Mojarra Only)

  • Verson 4.2.5-ga6 is the first production-quality version of Liferay Faces to support JSF 2.2.
  • All testing was performed with Mojarra 2.2.12. MyFaces is not supported by Liferay EE.
  • Refer to the new jsf2-flows-portlet and jsf2-html5-portlet for examples of how to use JSF 2.2 in a portlet environment.
  • Developed under JSR 344, JSF 2.2 is part of the larger Java EE 7 specification from the JCP. Even though Java EE 7 includes technologies like CDI 1.1 and Servlet 3.1, JSF 2.2 only depends on Java EE 6 technologies like CDI 1.0 and Servlet 3.0. This means that JSF 2.2 webapps and portlets can be deployed in Java EE 6 (Servlet 3.0) servlet containers such as Tomcat 7. However, Java EE 6 full-profile application servers such as GlassFish 3.2, JBoss 7.1, and WebLogic 12c bundle JSF 2.1 and cannot be upgraded to JSF 2.2. At the time of this writing, Liferay, Inc. has not released any Liferay Portal 6.2 bundles with Java EE 7 servers such as Tomcat 8, GlassFish 4.0 or JBoss/WildFly 8. Therefore version 4.2.5-ga6 is only supported Liferay Portal 6.2 on Tomcat 7.

API Changes

As outlined in FACES-1902FACES-1970FACES-2021, FACES-2025, and FACES-2166, there have been some changes to the Liferay Faces API. However since many of these changes were additions and/or clarifications to Liferay Faces API, upgrading to GA6 should be possible for most projects. If it is not possible to upgrade your projects, then please consider upgrading to Liferay Faces GA5 and associated patches.
 

Deprecated Tags

The following tags have been deprecated in the 3.2.5-ga6 release and removed in the 4.2.5-ga6 release:

Deprecated Tag Replacement Tag
aui:button-row alloy:buttonRow
aui:col alloy:column
aui:convertLongList No replacement available
aui:field alloy:field
aui:fieldset alloy:fieldset
aui:form alloy:form
aui:importConstants alloy:loadConstants
aui:layout alloy:panelGroup
aui:list alloy:dataList
aui:list-item alloy:dataItem
aui:row alloy:row
aui:text-box-list No replacement available
aui:text-box-list-item No replacement available
aui:script alloy:outputScript
aui-cc:appendToCssClasses() No replacement available
aui-cc:button alloy:commandButton
aui-cc:input alloy:inputText, alloy:inputTextarea, alloy:inputSecret, or alloy:selectBooleanCheckbox
aui-cc:message alloy:message
aui-cc:messages alloy:messages
liferay-security:permissionsURL portal:permissionsURL
portal:captcha
liferay-ui:icon-menu No replacement available
liferay-ui:input-editor portal:inputRichText
liferay-ui:ice-info-data-paginator No replacement available
liferay-ui:ice-nav-data-paginator No replacement available
liferay-ui:ice-page-iterator No replacement available
liferay-ui:icon No replacement available
alloy:outputText
liferay-ui:message alloy:outputText
liferay-ui:panel alloy:panel
liferay-ui:panel-container alloy:panelGroup
liferay-ui:portlet-toolbar alloy:panelGroup
alloy:panelGroup
liferay-ui:separator alloy:panelGroup
liferay-util:validateCaptcha Validation is automatically built-in to portal:captcha
liferay-util:validateRichTextLength Validation is provided by portal:inputRichText via the minPlainTextChars and maxPlainTextChars attributes

Project Links

Version Scheme

Please refer to the Liferay Faces Version Scheme for a detailed explanation of the version numbering.

Thank You

Thanks to everyone in the community that reported issues, contributed patches, and participated in the forums!

Liferay Faces Project News - May 2015

Company Blogs 12 mai 2015 Par Neil Griffin Staff

Project News

The Liferay Faces team is hard at work on several projects and I would like to bring you up-to-date with our progress.

Support for Liferay Portal 7.0

In early May I attended the Liferay Core Developers Conference in Madrid. One of my main goals in attending the conference was to gain a more complete understanding of the requirements for supporting OSGi portlets. I believe that this goal was reached and the Liferay Faces team is better prepared to implement these requirements to support JSF developers.

One of the many benefits that OSGi brings to Liferay Portal is increased modularity and the ability to better adhere to Semantic Versioning. In order to take advantage of this, the Liferay Faces project will need to move away from the umbrella project version scheme to individual, semantically versioned modules. Stay tuned for future project news as we make more progress in this area.

Another change for Liferay Portal 7.0 will be AlloyUI migrating from YUI to jQuery. As part of this migration, the corresponding JSF component renderers in Liferay Faces will be refactored to manifest jQuery-based JavaScript. The goal is to make it possible for JSF portlet developers to upgrade their Liferay 6.2 based portlets to Liferay 7.0 portlets with minimal effort.

Support for Liferay Portal 6.2

For most of 2014 and 2015 we have been focussed on developing new JSF components and our new Liferay Faces Showcase. As of the time of this writing, the latest version is 4.2.0-beta and we are working on the following Release Candidates:

  • Liferay Faces 4.2.5-rc1 (JSF 2.2 + Liferay Portal 6.2)
  • Liferay Faces 3.2.5-rc1 (JSF 2.1 + Liferay Portal 6.2)

Since the 4.2.5 and 3.2.5 releases support Liferay Portal 6.2, they include our new JSF components for AlloyUI 2.0 (the version of AlloyUI that comes bundled with the portal).

BTW, did you notice the minor revision jump from 4.2.0-beta to 4.2.5-rc1? For the sake of consistency, we decided on "4.2.5" in order to communicate the concept that the 4.2.x branch (a.k.a. the master branch) is at the same level of maturity as the 3.2.x branch. We did something similar in the past when we released version 3.2.4-ga5 (there had never been a 3.2.3-ga4, 3.2.2-ga3, 3.2.1-ga2, or 3.2.0-ga1 release before). Perhaps now you see why it is so important for us to move to Semantic Versioning with Liferay Portal 7.0, so that we can avoid the complications that our current version scheme can cause.

Support for Liferay Portal 6.1 / 6.0 / 5.2

Bug-fixes that have been committed to the master branch have also been backported to all other branches (as applicable). Although we do not plan release candidates for all branches, our GA6 release will also include:

  • Liferay Faces 3.1.5-ga6 (JSF 2.1 + Liferay Portal 6.1)
  • Liferay Faces 3.0.5-ga6 (JSF 2.1 + Liferay Portal 6.0)
  • Liferay Faces 3.0.5-legacy-ga6 (JSF 2.1 + Liferay Portal 5.2)
  • Liferay Faces 2.2.5-ga6 (JSF 1.2 + Liferay Portal 6.2)
  • Liferay Faces 2.1.5-ga6 (JSF 1.2 + Liferay Portal 6.1)

What's Next?

After the GA6 release, the Liferay Faces team will focus on GA7 which will contain maintenance repairs for GA6 as well as some additional JSF components. We will simultaneously be working towards support for Liferay Portal 7.0 and OSGi-based JSF portlets.

 

Announcement: Liferay Faces 4.2.0-beta Released

Company Blogs 27 avril 2015 Par Neil Griffin Staff

On April 28, 2015 Liferay released Liferay Faces 4.2.0-beta:

Liferay Faces 4.2.0-beta JSF 2.2 + Liferay Portal 6.2 Release Notes

Feature Complete

This new version of Liferay Faces is just about 100% feature complete which is why we decided to advance the version from "milestone" to "beta" status.

New Showcase Components

The Liferay Faces Showcase is hosted at www.liferayfaces.org and features a suite of new Java-based JSF components, many of which utilize AlloyUI and can be used in either webapps or portlets. Here is a list of the new components that have been developed since our 4.2.0-m2 release back in September, 2014:

For more information about our new Component Suite, see Juan Gonzalez' blog post titled New Liferay Faces release - Portal components and Vernon Singleton's blog post titled New Liferay Faces release - The alloy:accordion component.

Support for PrimeFaces 5.2

Thanks to our technology partnership with PrimeTek Informatics, we were able to resolve several portlet-related compatibility issues with PrimeFaces. In addition, we upgraded the new primefaces5-portlet and primefaces5-users-portlet demos to PrimeFaces 5.2.

Download Instructions

Since the 4.2.0-beta release is not General Availability (GA), the JAR artifacts are *not* published at Maven Central. Instead, they are published at the new Liferay Previews Nexus Repository along with the demo portlets.

Maven Project Dependencies

<dependencies>
  <dependency>
    <groupId>com.liferay.faces</groupId>
    <artifactId>liferay-faces-alloy</artifactId>
    <version>4.2.0-beta</version>
  </dependency>
  <dependency>
    <groupId>com.liferay.faces</groupId>
    <artifactId>liferay-faces-bridge-impl</artifactId>
    <version>4.2.0-beta</version>
  </dependency>
  <dependency>
    <groupId>com.liferay.faces</groupId>
    <artifactId>liferay-faces-portal</artifactId>
    <version>4.2.0-beta</version>
  </dependency>
</dependencies>
<repositories>
  <repository>
    <id>liferay-previews</id>
    <url>
      https://repository.liferay.com/nexus/content/repositories/liferay-previews
    </url>
  </repository>
</repositories>

Ivy Project Dependencies

<dependencies>
  <dependency org="com.liferay.faces" name="liferay-faces-alloy" rev="4.2.0-beta" />
  <dependency org="com.liferay.faces" name="liferay-faces-bridge-impl" rev="4.2.0-beta" />
  <dependency org="com.liferay.faces" name="liferay-faces-portal" rev="4.2.0-beta" />
</dependencies>
...
<resolvers>
  <ibiblio m2compatible="true" name="liferay-previews"
    root="https://repository.liferay.com/nexus/content/repositories/liferay-previews" />
</resolvers>

Version Scheme

Please refer to the Liferay Faces Version Scheme wiki article for a detailed explanation of the version numbering.

Stability

This 4.2.0-beta release is a technology preview that is suitable for development purposes but should not be used in a production environment. It will not be supported under the Liferay EE subscription until it reaches GA (General Availability) status.

Support For JSF 2.2 and Liferay Portal 6.2

  • This release of Liferay Faces is compatible with JSF 2.2

  • If deploying portlets to Liferay Portal 6.2, then developers should read the new Migrating From Liferay Faces 3.1 to Liferay Faces 3.2/4.2 section in the Developer's Guide. Specifically, JSF portlets require the following option in the WEB-INF/liferay-portlet.xml descriptor: <requires-namespaced-parameters>false</requires-namespaced-parameters>

Tomcat 7 Only

Developed under JSR 344, JSF 2.2 is part of the larger Java EE 7 specification from the JCP. Even though Java EE 7 includes technologies like CDI 1.1 and Servlet 3.1, JSF 2.2 only depends on Java EE 6 technologies like CDI 1.0 and Servlet 3.0. This means that JSF 2.2 webapps and portlets can be deployed in Java EE 6 (Servlet 3.0) servlet containers such as Tomcat 7. However, Java EE 6 full-profile application servers such as GlassFish 3.2, JBoss 7.1, and WebLogic 12c bundle JSF 2.1 and cannot be upgraded to JSF 2.2. At the time of this writing, Liferay, Inc. has not released any Liferay Portal 6.1/6.2 bundles with Java EE 7 servers such as Tomcat 8, GlassFish 4.0 or JBoss/WildFly 8. Therefore this milestone has only been tested for compatibility with Liferay Portal 6.1/6.2 on Tomcat 7.
 

Roadmap

The Liferay Faces team is hard at work adding new components and new features so that we can achieve Release Candidate (RC) status in our next release. Stay tuned!
 

Feedback Requested

If you find any problems with this release, please post a message in the Liferay Faces forums.

Announcement: Patches for Liferay Faces GA5

Company Blogs 3 février 2015 Par Neil Griffin Staff

The Liferay Faces team is focussed on developing our new 4.2.5-GA6 and 3.2.5-GA6 releases as well as our new Liferay Faces Showcase demo.

But since not all projects will not have an opportunity to upgrade, we developed the following patches for our GA5 release:

Issue Description Version(s)
FACES-1513 Portlet incompatibility with PrimeFaces p:dataExporter and p:fileDownload 3.2.4-ga5, 3.1.4-ga5, 3.0.4-ga5
FACES-1917 Security vulnerability with _jsfBridgeViewId, _facesViewIdRender, and _facesViewIdResource URL parameter values 3.2.4-ga5, 3.1.4-ga5, 3.0.4-ga5, 3.0.4-legacy-ga5, 2.2.4-ga5, 2.1.4-ga5
FACES-2006 BridgeFactoryFinderImpl not thread safe 3.2.4-ga5, 3.1.4-ga5, 3.0.4-ga5, 3.0.4-legacy-ga5, 2.2.4-ga5, 2.1.4-ga5
FACES-2007 PrimeFaces 5.1 portlet incompatibility with getFacesResource function in primefaces.js

Note that the following line must be added to each Facelet view in order to make use of the patch:

<h:outputScript name="primefaces-override.js" library="liferay-faces-2007-patch" />
3.2.4-ga5, 3.1.4-ga5
FACES-2043
JavaScript error 'TypeError: editorNode is null' occurs with liferay-ui:input-editor and Liferay Portal 6.2 EE SP5
3.2.4-ga5
FACES-2056 Liferay Faces Bridge does not support adding PrimeFaces 5.x scripts before the closing </body> tag of the portal page 3.2.4-ga5, 3.1.4-ga5
FACES-2061 Liferay Faces Bridge does not support PrimeFaces 4.x/5.x client side validation 3.2.4-ga5, 3.1.4-ga5
FACES-2343 Security vulnerability with accessing resources in JSF portlets 3.2.4-ga5, 3.1.4-ga5, 3.0.4-ga5, 3.0.4-legacy-ga5, 2.2.4-ga5, 2.1.4-ga5
FACES-2361 Security vulnerability with accessing a non-Faces view in JSF portlets 3.2.4.1-ga5, 3.1.4.1-ga5, 3.0.4.1-ga5, 3.0.4.1-legacy-ga5, 2.2.4.1-ga5, 2.1.4.1-ga5

Maven Dependencies

The following dependencies can be applied to each portlet WAR project. Version 3.2.4-ga5 is shown for example purposes. Please refer to the table above for patch applicability for each GA5 version of Liferay Faces.

<dependencies>
  <dependency>
    <groupId>com.liferay.faces.patches</groupId>
    <artifactId>liferay-faces-1513-patch</artifactId>
    <version>3.2.4-ga5</version>
  </dependency>
  <dependency>
    <groupId>com.liferay.faces.patches</groupId>
    <artifactId>liferay-faces-1917-lsv-5-patch</artifactId>
    <version>3.2.4-ga5</version>
  </dependency>
  <dependency>
    <groupId>com.liferay.faces.patches</groupId>
    <artifactId>liferay-faces-2006-patch</artifactId>
    <version>3.2.4-ga5</version>
  </dependency>
  <dependency>
    <groupId>com.liferay.faces.patches</groupId>
    <artifactId>liferay-faces-2007-patch</artifactId>
    <version>3.2.4-ga5</version>
  </dependency>
  <dependency>
    <groupId>com.liferay.faces.patches</groupId>
    <artifactId>liferay-faces-2043-patch</artifactId>
    <version>3.2.4-ga5</version>
  </dependency>
  <dependency>
    <groupId>com.liferay.faces.patches</groupId>
    <artifactId>liferay-faces-2056-patch</artifactId>
    <version>3.2.4-ga5</version>
  </dependency>
  <dependency>
    <groupId>com.liferay.faces.patches</groupId>
    <artifactId>liferay-faces-2061-patch</artifactId>
    <version>3.2.4-ga5</version>
  </dependency>
  <dependency>
    <groupId>com.liferay.faces.patches</groupId>
    <artifactId>liferay-faces-2343-lsv-71-patch</artifactId>
    <version>3.2.4-ga5</version>
  </dependency>
  <dependency>
    <groupId>com.liferay.faces</groupId>
    <artifactId>liferay-faces-bridge-api</artifactId>
    <version>3.2.4.1-ga5</version>
  </dependency>
</dependencies>

 

Announcement: Liferay Faces 4.2.0-m2 Released

Company Blogs 26 septembre 2014 Par Neil Griffin Staff

On September 26, 2014 Liferay released the 2nd Milestone of Liferay Faces 4.2.0:

Liferay Faces 4.2.0-m2 JSF 2.2 + Liferay Portal 6.2 Release Notes

All New Showcase

The Liferay Faces Showcase has is hosted at www.liferayfaces.org and features a suite of new Java-based JSF components, many of which utilize AlloyUI and can be used in either webapps or portlets.

Responsive JSF

  • Since AlloyUI relies on Twitter Bootstrap, bootstrap-responsive.min.css is automatically included as a @ResourceDependency
  • Developers can design responsive layouts using the alloy:row component
  • There is a "responsive" attribute (defaults to true) on alloy:inputDate and alloy:inputTime so that they use the native date/time pickers on mobile displays
  • The portal:navBar component is responsive as well, turning itself into a button with a popup menu for smaller (mobile) displays

Download Instructions

Since the 4.2.0-m2 release is not General Availability (GA), the JAR artifacts are *not* published at Maven Central. Instead, they are published at the new Liferay Previews Nexus Repository along with the demo portlets.

Maven Project Dependencies

<dependencies>
  <dependency>
    <groupId>com.liferay.faces</groupId>
    <artifactId>liferay-faces-alloy</artifactId>
    <version>4.2.0-m2</version>
  </dependency>
  <dependency>
    <groupId>com.liferay.faces</groupId>
    <artifactId>liferay-faces-bridge-impl</artifactId>
    <version>4.2.0-m2</version>
  </dependency>
  <dependency>
    <groupId>com.liferay.faces</groupId>
    <artifactId>liferay-faces-portal</artifactId>
    <version>4.2.0-m2</version>
  </dependency>
</dependencies>
<repositories>
  <repository>
    <id>liferay-previews</id>
    <url>
      https://repository.liferay.com/nexus/content/repositories/liferay-previews
    </url>
  </repository>
</repositories>

Ivy Project Dependencies

<dependencies>
  <dependency org="com.liferay.faces" name="liferay-faces-alloy" rev="4.2.0-m2" />
  <dependency org="com.liferay.faces" name="liferay-faces-bridge-impl" rev="4.2.0-m2" />
  <dependency org="com.liferay.faces" name="liferay-faces-portal" rev="4.2.0-m2" />
</dependencies>
...
<resolvers>
  <ibiblio m2compatible="true" name="liferay-previews"
    root="https://repository.liferay.com/nexus/content/repositories/liferay-previews" />
</resolvers>

Version Scheme

Please refer to the Liferay Faces Version Scheme wiki article for a detailed explanation of the version numbering.

Stability

This 4.2.0-m2 release is a technology preview that is suitable for development purposes but should not be used in a production environment. It will not be supported under the Liferay EE subscription until it reaches GA (General Availability) status.

Support For JSF 2.2 and Liferay Portal 6.2

  • This release of Liferay Faces is compatible with JSF 2.2

  • If deploying portlets to Liferay Portal 6.2, then developers should read the new Migrating From Liferay Faces 3.1 to Liferay Faces 3.2/4.2 section in the Developer's Guide. Specifically, JSF portlets require the following option in the WEB-INF/liferay-portlet.xml descriptor: <requires-namespaced-parameters>false</requires-namespaced-parameters>

Tomcat 7 Only

Developed under JSR 344, JSF 2.2 is part of the larger Java EE 7 specification from the JCP. Even though Java EE 7 includes technologies like CDI 1.1 and Servlet 3.1, JSF 2.2 only depends on Java EE 6 technologies like CDI 1.0 and Servlet 3.0. This means that JSF 2.2 webapps and portlets can be deployed in Java EE 6 (Servlet 3.0) servlet containers such as Tomcat 7. However, Java EE 6 full-profile application servers such as GlassFish 3.2, JBoss 7.1, and WebLogic 12c bundle JSF 2.1 and cannot be upgraded to JSF 2.2. At the time of this writing, Liferay, Inc. has not released any Liferay Portal 6.1/6.2 bundles with Java EE 7 servers such as Tomcat 8, GlassFish 4.0 or JBoss/WildFly 8. Therefore this milestone has only been tested for compatibility with Liferay Portal 6.1/6.2 on Tomcat 7.
 

Roadmap

The Liferay Faces team is hard at work adding new components and new features so that we can achieve BETA status in our next release. Stay tuned!
 

Feedback Requested

If you find any problems with this release, please post a message in the Liferay Faces forums.

The Future is Bright for JSF

Company Blogs 5 août 2014 Par Neil Griffin Staff

Today's JSF

JavaServer Faces (JSF) is a Java EE standard technology that enjoys wide support with Java EE application servers including JBoss AS/WildFly, Oracle WebLogic, and IBM WebSphere. In addition, JSF developers benefit from tooling support built-in to Eclipse, NetBeans, and IntelliJ. Over the years, JSF has received many features and improvments thanks to dedicated JCP Expert Groups led by Ed Burns and innovative ideas contributed from open source projects.

JSF component suites like ICEfaces, PrimeFaces, and RichFaces offer a plethora of UI components and advanced features, all built on top of the core JSF standard. Each of these component suites boasts an online "showcase" type of webapp that shows how to use the components in typical use-cases.

JSF 2.0/2.1 was released with Java EE 6 and was well received by developers thanks to the addition of standards-based Ajax features and the adoption of Facelets as the standard templating engine. JSF 2.2 was released with Java EE 7 and added fantastic new features like Faces Flows.

JSF Portlets

Thanks to JSR 329, JSF is fully compatible with Portlet 2.0, another standard from the JCP. The Liferay Faces project is supported under Liferay EE and provides a standards-compliant JSF portlet bridge. With added support from Liferay IDE, developers can easily deploy JSF portlets built with ICEfaces/PrimeFaces/RichFaces within Liferay Portal. In addition, Liferay, Inc. has a technology partnership with ICEsoft and a partnership with PrimeTek in order to support our mutual customers.

Tomorrow's JSF

Recently, Liferay announced a major upgrade to Liferay Faces, which includes support for JSF 2.2 and a suite of JSF components for AlloyUI. ICEsoft has announced ICEfaces 4.0, and the PrimeTek blog has frequent updates on PrimeFaces 5.1. The new Portlet 3.0 standard is being developed under JSR 362 and features optimized support for JSF. Finally, Ed Burns announced Oracle's intention to file a new JSR for JSF 2.3.

The future is bright indeed for JSF. smiley

-- Neil

Liferay Faces Project News - July 2014

Company Blogs 21 juillet 2014 Par Neil Griffin Staff

Liferay Faces Showcase

The Liferay Faces team has been hard at work on the new Liferay Faces Showcase which demonstrates the new JSF components we are developing. Many of the components utilize Liferay's AlloyUI technology (which is based on YUI3 and Twitter Bootstrap).

Component Design Features:

  • The new AlloyUI JSF components will work with Liferay Faces 4.2 (JSF 2.2) and Liferay Faces 3.2 (JSF 2.1)
  • Although the new AlloyUI JSF components require Liferay Portal 6.2, they will also work in a plain webapp!
  • When running in a plain webapp, the new AlloyUI JSF components provide the YUI3 and AlloyUI 2.0.0 JavaScript resources automatically.
  • Our goal is to have the new AlloyUI JSF components be able to exist in the same JSF view as ICEfaces/PrimeFaces/RichFaces components. This should be technologically possible since this was one of the original design goals of JSF, and the other component suites are based on jQuery.

Stay tuned for a technology preview in the coming weeks! smiley

Facelet Tag Library Namespaces

Liferay Faces is an umbrella project that is comprised of several sub-projects. In order to make it easier to identify which components are associated to a sub-project, we decided to simplify the Facelet Tag Library namespaces:

Namespace Prefix Sub-Project
alloy: Liferay Faces Alloy
bridge: Liferay Faces Bridge
portal: Liferay Faces Portal 

Team Members

Back in January of 2014, Liferay's Bruno Basto became a contributor to our team by helping us develop a code generator for AlloyUI JSF components.

Since then Kyle Stiemann has made the code generator more robust which has strengthened the overall quality of the software. Kyle has also developed JSF components like alloy:button, alloy:commandButton, alloy:icon, alloy:inputDate, and alloy:panelGroup.

Vernon Singleton has developed JSF components like alloy:outputText, alloy:outputRemainingChars, alloy:selectOneRadio, alloy:selectStarRating, alloy:selectThumbRating, and alloy:accordion.

I've been working on the Showcase portlet itself, and also developing components like alloy:inputSourceCode, alloy:tabView, etc. Working on the Showcase has been lots of fun because it is built with Liferay Faces.

Again, stay tuned for our technology preview in the coming weeks!smiley

-- Neil


Left to right: Bruno Basto, Kyle Stiemann, Vernon Singleton, and Neil Griffin

Announcement: Liferay Faces 4.x M1 Released

Company Blogs 3 mars 2014 Par Neil Griffin Staff

On March 1, 2014 Liferay released the 1st Milestone of Liferay Faces 4.x:

Liferay Faces 4.2.0-m1 JSF 2.2 + Liferay Portal 6.2 *NEW* Release Notes
Liferay Faces 4.1.0-m1 JSF 2.1 + Liferay Portal 6.1 *NEW* Release Notes

Download Instructions

Since the 4.2.0-m1 and 4.1.0-m1 releases are not General Availability (GA), the JAR artifacts are *not* published at Maven Central. Instead, they are published at the new Liferay Previews Nexus Repository along with the demo portlets.

Maven Project Dependencies

<dependencies>
  <dependency>
    <groupId>com.liferay.faces</groupId>
    <artifactId>liferay-faces-alloy</artifactId>
    <version>4.2.0-m1</version>
  </dependency>
  <dependency>
    <groupId>com.liferay.faces</groupId>
    <artifactId>liferay-faces-bridge-impl</artifactId>
    <version>4.2.0-m1</version>
  </dependency>
  <dependency>
    <groupId>com.liferay.faces</groupId>
    <artifactId>liferay-faces-portal</artifactId>
    <version>4.2.0-m1</version>
  </dependency>
</dependencies>
<repositories>
  <repository>
    <id>liferay-previews</id>
    <url>
      https://repository.liferay.com/nexus/content/repositories/liferay-previews
    </url>
  </repository>
</repositories>

Ivy Project Dependencies

<dependencies>
  <dependency org="com.liferay.faces" name="liferay-faces-alloy" rev="4.2.0-m1" />
  <dependency org="com.liferay.faces" name="liferay-faces-bridge-impl" rev="4.2.0-m1" />
  <dependency org="com.liferay.faces" name="liferay-faces-portal" rev="4.2.0-m1" />
</dependencies>
...
<resolvers>
  <ibiblio m2compatible="true" name="liferay-previews"
    root="https://repository.liferay.com/nexus/content/repositories/liferay-previews" />
</resolvers>

Version Scheme

Please refer to the Liferay Faces Version Scheme wiki article for a detailed explanation of the version numbering.

Stability

This 4.x M1 release is based off the stable codebase of the 3.x GA5 release. The main difference is support for JSF 2.2 and new demo portlets (see below). This M1 (Milestone) release is suitable for development purposes, however 4.x will not be supported under the Liferay EE subscription until it reaches GA (General Availability) status.

Support For JSF 2.2

  • This is the first release of Liferay Faces that is compatible with JSF 2.2

  • If deploying portlets to Liferay Portal 6.2, then developers should read the new Migrating From Liferay Faces 3.1 to Liferay Faces 3.2/4.2 section in the Developer's Guide. Specifically, JSF portlets require the following option in the WEB-INF/liferay-portlet.xml descriptor: <requires-namespaced-parameters>false</requires-namespaced-parameters>

Tomcat 7 Only

Developed under JSR 344, JSF 2.2 is part of the larger Java EE 7 specification from the JCP. Even though Java EE 7 includes technologies like CDI 1.1 and Servlet 3.1, JSF 2.2 only depends on Java EE 6 technologies like CDI 1.0 and Servlet 3.0. This means that JSF 2.2 webapps and portlets can be deployed in Java EE 6 (Servlet 3.0) servlet containers such as Tomcat 7. However, Java EE 6 full-profile application servers such as GlassFish 3.2, JBoss 7.1, and WebLogic 12c bundle JSF 2.1 and cannot be upgraded to JSF 2.2. At the time of this writing, Liferay, Inc. has not released any Liferay Portal 6.1/6.2 bundles with Java EE 7 servers such as Tomcat 8, GlassFish 4.0 or JBoss/WildFly 8. Therefore this milestone has only been tested for compatibility with Liferay Portal 6.1/6.2 on Tomcat 7.
 

JSF 2.2 Component Suites

Portlets can be developed with JSF 2.2 component suites including Liferay Faces Alloy and PrimeFaces 4.0. Future milestones will include planned support for ICEfaces 4.0 and RichFaces 5.0 portlets.
 

JSF 2.2 Feature Demos

In order to test JSF 2.2, we developed the following new demo portlets:

Roadmap

The Liferay Faces team is hard at work developing JSF components and a Showcase for AlloyUI 2.0. Stay tuned!
 

Feedback Requested

If you find any problems with this release, please post a message in the Liferay Faces forums.

Announcement: Liferay Faces 3.x / 2.x GA5 Released

Company Blogs 19 février 2014 Par Neil Griffin Staff

On February 15, 2014 Liferay released the 5th General Availability (GA) version of Liferay Faces:

Liferay Faces 3.2.4-ga5 JSF 2.1 + Liferay Portal 6.2 *NEW* Release Notes
Liferay Faces 3.1.4-ga5 JSF 2.1 + Liferay Portal 6.1 Release Notes
Liferay Faces 3.0.4-ga5 JSF 2.1 + Liferay Portal 6.0 Release Notes
Liferay Faces 3.0.4-legacy-ga5 JSF 2.1 + Liferay Portal 5.2 Release Notes
Liferay Faces 2.2.4-ga5 JSF 1.2 + Liferay Portal 6.2 *NEW* Release Notes
Liferay Faces 2.1.4-ga5 JSF 1.2 + Liferay Portal 6.1 Release Notes

Project Links

Version Scheme

Please refer to the Liferay Faces Version Scheme wiki article for a detailed explanation of the version numbering.

Support For Liferay Portal 6.2

  • This is the first release of Liferay Faces that has been certified as being compatibile with the new Liferay Portal 6.2 CE GA1 and 6.2 EE GA1 release

  • Developers can use version 3.2.4-ga5 for JSF 2.1, or version 2.2.4-ga5 for JSF 1.2

  • In order to upgrade portlets to Liferay Portal 6.2 compatibility, the DTD version numbers inside the of the Liferay XML descriptors should be updated:
    <!DOCTYPE display PUBLIC "-//Liferay//DTD Display 6.2.0//EN" "http://www.liferay.com/dtd/liferay-display_6_2_0.dtd">
    
    <!DOCTYPE hook PUBLIC "-//Liferay//DTD Hook 6.2.0//EN" "http://www.liferay.com/dtd/liferay-hook_6_2_0.dtd">
    <!DOCTYPE liferay-portlet-app PUBLIC "-//Liferay//DTD Portlet Application 6.2.0//EN" "http://www.liferay.com/dtd/liferay-portlet-app_6_2_0.dtd">
  • Developers should read the new Migrating From Liferay Faces 3.1 to Liferay Faces 3.2/4.2 section in the Developer's Guide. Specifically, JSF portlets require the following option in the WEB-INF/liferay-portlet.xml descriptor:

    <requires-namespaced-parameters>false</requires-namespaced-parameters>
  • The feature in Liferay Faces Bridge that detects duplicate versions of JSF resources in the <head>...<head> section of the portal page does not work with the out-of-the-box Liferay+Tomcat bundle. The reason why is because Liferay Portal 6.2 has a revamped "parallel rendering" engine that attempts to render portlets in parallel (rather than in serial) by default. Developers can add p_p_parallel=0 to the initial HTTP GET portal page URL to disable parallel rendering on a page-by-page basis, or it can be disabled globally by setting the value of the following property in the portal-ext.properties file:
    layout.parallel.render.enable=false
  • The following JSF Portlet Maven Archetypes have been updated to use version 3.2.4-ga5 Maven dependencies:
  • In addition, the JSF Portlet Ivy Templates in the Plugins SDK have been updated to use version 3.2.4-ga5 Ivy dependencies.
  • Liferay IDE 2.0 lets developers choose either Maven or Ivy as the project build type. New projects will be created from the aforementioned JSF Portlet Maven Archetypes and Ivy Templates will be used automatically when new JSF portlets are created via the wizard. 

Release Stats

This is a maintenance release that has 35+ bug fixes and 15+ features/improvements.

WebLogic 12c / 11g

Version 3.2.4-ga5 is compatible with WebLogic 12c. Version 3.1.4-ga5 is compatible with WebLogic 11g.
 

Documentation Changes

The Liferay Faces documentation was converted to MarkDown and is now Chapter 4 of the Liferay Portal 6.2 Developer Guide. We have plans to convert many of the Liferay Faces wiki articles MarkDown as well. When complete, they will be integrated into the "Installation and Setup" chapter of the Liferay Portal 6.2 User Guide. For now, please continue to reference the Liferay Faces Wiki.
 

New Demo: primefaces4-portlet

In order to test PrimeFaces 4.0, we developed a new primefaces4-portlet demo.
 

Thank You

Thanks to everyone in the community that reported issues, contributed patches, and participated in the forums!

Three Cheers for JSF 2.2 Faces Flows

General Blogs 18 décembre 2013 Par Neil Griffin Staff

Introduction

Java EE 7 includes the new JSR 344 (JSF 2.2) standard and provides developers with new features like Resource Library Contracts, HTML5 Friendly Markup, and Faces Flows. The Liferay Faces team is hard at work at providing 1st class support for JSF 2.2 in Liferay Faces 4.x including the following new portlet demos:

Webinar: Modern JSF Development

I recently had the privledge of showing these demos during a Liferay LIVE webinar titled Modern JSF Development. The webinar will be archived in a few weeks.

Personally I have to say that Faces Flows is my favorite feature in JSF 2.2. In fact, during the webinar one of the attendees wrote:

Wow.. Flows is a natural fit in Liferay... Excellent!

What Makes Faces Flows So Great?

Faces Flows is a standards-based Java EE feature that builds upon the lessons learned from projects like ADF Task Flows, Spring WebFlow, and Apache MyFaces CODIIt provides a way of connecting JSF views together and scoping data accordingly via the new @FlowScoped annotation and CDI.

@FlowScoped vs @ConversationScoped

The new JSF @FlowScoped annotation depends on CDI. At first glance it might seem similar to the CDI @ConversationScoped annotation, but it is a much better "fit" for JSF webapps/portlets because the developer doesn't need to make awkward programmatic calls to Conversation.begin() and Conversation.end() in a PhaseListener to make things work. Instead, beans annotated with @FlowScoped are created and destroyed automatically when the user navigates in and out of flows. In addition, developers can easily orchestrate sub-flows spawned from a parent flow and pass data between them using outbound and inbound parameters.

Let's take a closer look by examining the JSF2 Faces Flows Portlet demo...

Defining Flows

The portlet contains a main flow named "booking" and a sub-flow named "survey". The user (customer) books travel with Facelet views that are collected together in the "/booking" directory, and optionally completes a survey with Facelet views that are in the "/survey" directory.

As stated earlier, flows can pass data to each other using outbound and inbound parameters. If the customer takes the optional survey, then the customer's info is passed as an outbound parameter as defined in /booking/booking-flow.xml and received as an inbound parameter as defined in /survey/survey-flow.xml

Activating The Booking Flow

The initial view displayed by the portlet is /views/portletViewMode.xhtml

Simply clicking on the "Enter Booking Flow" button activates the "booking" flow:

<h:commandButton action="booking" value="#{i18n['enter-booking-flow']}">
	<f:ajax execute="@form" />
</h:commandButton>

Since the value of the action attribute is "booking", JSF will use convention-over-configuration to determine the target view for navigation. If it can't find a file named booking.xhtml in the same directory, it will attempt to find a directory named "/booking" and navigate to the view named /booking/booking.xhtml

Automatic Bean Scope Management by CDI

The portlet contains two model beans annotated with @FlowScoped:

When EL expressions like #{bookingFlowModelBean} or #{surveyFlowModelBean} are encountered by JSF in a Facelet view, the EL resolver chain will ask CDI to create an instance of BookingFlowModelBean.java or SurveyFlowModelBean.java respectively. Additionally, CDI will call any methods annotated with @PostConstruct such as BookingFlowModelBean.postConstruct() and SurveyFlowModelBean.postConstruct().

When the user navigates out of the "booking" flow or "survey" flow, then CDI will call any methods annotated with @PreDestroy such as BookingFlowModelBean.preDestroy() and SurveyFlowModelBean.preDestroy().

Final Thoughts

JSF portlet developers finally have a standards-based feature for creating wizard-like portlets. Gone are the integration headaches of making 3rd party flow add-ons work inside a portlet environment. The @FlowScoped annotation provides an elegant programming model and makes @ConversationScoped obsolete in many JSF use-cases. In addition, navigation between views can be fully ajaxified via f:ajax without writing any JavaScript.

All I can say is THREE CHEERS for Faces Flows!

+1 +1 +1 (pronounced Hip Hip Hooray in the olden days)

 

Announcement: Liferay Faces 3.1.3-ga4 Released

Company Blogs 6 septembre 2013 Par Neil Griffin Staff

On September 5, 2013 Liferay released the 4th General Availability (GA) release of Liferay Faces:

  • Liferay Faces 3.1.3-ga4 (JSF 2.1 + Liferay 6.1.x -- including 6.1.2 CE and 6.1.30 EE)
  • Liferay Faces 3.0.3-ga4 (JSF 2.1 + Liferay 6.0.x)
  • Liferay Faces 3.0.3-legacy-ga4 (JSF 2.1 + Liferay 5.2.x)
  • Liferay Faces 2.1.3-ga4 (JSF 1.2 + Liferay 6.1.x)

Project Links

Version Scheme

Please refer to the Liferay Faces Version Scheme wiki article for a detailed explanation of the version numbering.

Release Highlights

This is a maintenance release that has 35+ bug fixes25+ improvements, and 5+ new features. For full details, please refer to the Release Notes. This is the first release of Liferay Faces that has been certified as being compatibile with the new Liferay Portal 6.1.2 CE GA3 and 6.1.30 EE GA3 releases.
 

VDLDocs

The Facelet taglib documentation has been moved out of the PDF documentation directly into the taglib files and Facelet Composite Component files. We are now using the vdldoc project to generate View Description Language (VDL) documentation: http://docs.liferay.com/faces/3.1/vdldoc/
 

Updated Wiki Articles

Many of the Liferay Faces wiki articles have been updated with instructions for deploying JSF portlets on various servers ( GlassFish, Jetty, JBoss AS, Resin, Tomcat, WebLogic, and WebSphere) as well as upgrading Mojarra and Weld.
 

New Demo: jsf2-spring-portlet

In order to test the Spring Framework, we developed a new jsf2-spring-portlet demo that shows how to use annotations like javax.inject.Injectjavax.inject.Named, and org.springframework.context.annotation.Scope("request").
 

Critical Bug Fixes / Improvements

It is no longer necessary to specify the Mojarra ConfigureListener or the Liferay Faces BridgeSessionListener in the WEB-INF/web.xml descriptors of portlets. In addition, the following is a list if critical bug fixes / improvements:

  • [FACES-1706] - Upgrade 3.1.x and 2.1.x branches from Liferay Portal 6.1.1 to Liferay Portal 6.1.2 API
  • [FACES-1656] - Provide ability to discover Mojarra InjectionProvider during execution of the JSF lifecycle
  • [FACES-1655] - Enable zero-config of com.liferay.faces.bridge.servlet.BridgeSessionListener by registering it in liferay-faces-bridge-impl!META-INF/bridge.tld
  • [FACES-1664] - Develop shared library modules for WebLogic
  • [FACES-1675] - Add reference to jsf shared library to weblogic.xml descriptors
  • [FACES-1619] - UnsupportedOperationException when trying to add JSF portlets to a portal page dynamically
  • [FACES-1674] - Resource libraries/collections are not marked as being added to the <head>...</head> section of the portal page
  • [FACES-1713] - liferay-ui:input-editor does not store aui:script text in WebKeys.AUI_SCRIPT_DATA request attribute during ajax requests on versions of Liferay Portal prior to 6.1.2/6.1.30

Thank You

Thanks to everyone in the community that reported issues, contributed patches, and participated in the forums!

Maven Tip: Activating Profiles With Multiple Conditions

General Blogs 10 août 2013 Par Neil Griffin Staff

When working with Maven profiles, sometimes you need to activate a profile when multiple conditions are true. Although the <activation> element in pom.xml lets you specify more than one condition, the conditions are evaluated with the OR operator rather than the AND operator.

When Maven executes profiles, it executes them in the following manner:

  • Profiles that were specified with the "-P" command line switch, according to their order of appearance in the pom
  • All other profiles that might conditionally activate, such as profiles that activate based on the existence of a file in the current module

Using this knowledge of profile execution, I came up with a way of activating profiles when multiple conditions are true, based on the presence of a temporary file whose name has one or more property values.

HOWEVER... this only works when Maven is executed in a directory that contains a parent pom. It does not work in a sub-module (like a war project), because the temporary file is created after all of the profiles have been activated.

Example: Only include Xerces as a dependency for portlet WAR projects that are to be deployed on WebLogic:

<profiles>
    <!-- The following profile must appear before other profiles -->
    <!-- and is activated only when WEB-INF/portlet.war is found -->
    <profile>
        <id>activate-portlet-war</id>
        <activation>
            <file>
                <exists>src/main/webapp/WEB-INF/portlet.xml</exists>
            </file>
        </activation>
        <build>
            <plugins>
                <plugin>
                    <artifactId>maven-antrun-plugin</artifactId>
                    <executions>
                        <execution>
                            <phase>generate-resources</phase>
                            <goals>
                                <goal>run</goal>
                            </goals>
                            <configuration>
                                <target>
                                    <touch file="target/${app.server.type}-portlet-war-activation.tmp" />
                                </target>
                            </configuration>
                        </execution>
                    </executions>
                </plugin>
            </plugins>
        </build>
    </profile>
    <!-- The following profile is activated with "-P weblogic" on the command line -->
    <profile>
        <id>weblogic</id>
        <properties>
            <app.server.type>weblogic</app.server.type>
        </properties>
    </profile>
    <!-- The following profile is activated only for weblogic portlet wars -->
    <profile>
        <id>weblogic-portlet-war</id>
        <activation>
            <file>
                <exists>target/weblogic-portlet-war-activation.tmp</exists>
            </file>
        </activation>
        <dependencies>
            <dependency>
                <groupId>xerces</groupId>
                <artifactId>xercesImpl</artifactId>
                <version>2.11.0</version>
            </dependency>
        </dependencies>
    </profile>
</profiles>

This is an approach that can be used in Maven 2/3. Perhaps MNG-4565 will be implemented as a feature in some future version of Maven.

Affichage des résultats 1 - 20 parmi 55.
Items 20
de 3