Blogs

Technological Updates

—Tomcat 8—

—JDK 8

—Mysql 5.7—

—Eclipse Update / Liferay IDE 3

Look and Feel :

—Lexicon Design Language

—set of patterns (visual and interaction)

—designed to be fluid and extensible

—Optimized product navigation

—New Forms user experience

—Geolocate any content

—New image, file and media selector

—Fast response - avoiding full page refreshes

—Single Page Applications – senna.js

Very Good News - IE support 10,11/Edg

Bootstrap 3.0 Look and Feel

Modularity - OSGI

—Monolithic to Microservices

—Now 500+ new modules (bundles in the osgi world),

—We can change any way we like, simply by overriding them with our own modules.

How OSGI :

—Liferay Module Framework

—Apache Felix

—Declarative Services (replaces .xml configurations)

—Bndtools

—Gogo Shell for manipulating the module lifecycle and many other things

—Semantic Versioning

Blade Tool/Blade CLI

No ext plugins any more.

Other changes :

—Lucene Gone, Elastic Search(Separate Server)

—Optionally Solr, support only in EE

—Goodbye Ant, Hello Gradle (maven is still there)

—Build tool based on Node.js for Theme development

—New mobile SDK with Liferay screens 2

Clustering not supported in CE

Here are some key changes of interest to existing Liferay developers:

Extraction of many features as modules: So far you have been used to working with Liferay as a large web application, of which all of it had to be deployed or none of it. In Liferay Portal CE 7.0, many out of the box portlets, features, and associated APIs have been extracted as OSGi modules. Developers can choose which ones to deploy and use.

Adoption of modern OSGi standards: OSGi is a set of standards for building modular systems. It’s very powerful. Although it was previously difficult to learn and use, its modernized standards, such as Declarative Services, have made learning and using it much much easier.

Core Public APIs are provided through portal-kernel (previously known as portal-service); all other public APIs are provided by their own modules.

You can reuse modules and libraries, and manage the dependencies among them.

Registration of classes implementing extension points is now simpler and more consistent; it’s based on the standard @Component annotation instead of declarations it in portal.properties (in some cases) or portlet.xml (in some others). Note, previous registration mechanisms have been preserved where possible.

Third party extensions and applications are now first-class citizens. Traditional plugins had some limitations that developments done in the core (or done as Ext Plugins) did not have. Modules don’t have these limitations and are much more powerful than plugins ever were.

What has not changed? Even though there are many improvements in Liferay Portal CE 7.0, there are also many great familiar aspects from previous versions that have been preserved. Here are some of the most relevant ones:

The Portal Core and each Liferay app continue to use the three layer architecture: presentation, services, and persistence. The presentation layer is now always provided as an independent module, facilitating replacing it with a different presentation, if desired.

Support remains for previously supported standards such as Portlets (JSR-168, JSR-286), CMIS, WebDAV, LDAP, JCP (JSR-170), etc.

Most Liferay APIs have remained functionally similar to those of 6.2, even if many of their classes have moved to new packages, as part of the modularization effort.

Liferay IDE is still the preferred tool to develop for Liferay, even though you are still free to use tools that best fit your needs.

Service Builder and other developer tools and libraries continue to work as they have in 6.2.

Traditional plugins for portlets and hooks still work (once they’re adapted to Liferay Portal CE 7.0’s API) through a compatibility layer.

The legacy Plugins SDK can also still be used and transition to the new Liferay Workspace, if desired, is easy.

Since the modularization of the Liferay web application is the change most relevant to you as a developer, let’s dig deeper into that change and how it affects Liferay’s architecture.