Ask Questions and Find Answers

I'm looking forward to it also.  I don't know yet how it will rock my world as I can already build portlets today, but likely once I'm knee deep into it I'll be like, yeah, this is da bomb!

Iñaki Paz Rey:

To amend Olaf comment, the final document was produced by 12 of December 2016 (almost 2 years) and Liferay was there knowing that it would be the final version. The rest is burocracy to release that document as final version and recommendation. I remember that JSR 286 was implemented much faster ;-) with previews even before the Standard was finally released. 

Oh, I'm sorry, which other portal vendors, also sitting at the same table, have implemented Portlet 3?  Oh, yeah, NONE OF THEM.

Iñaki Paz Rey:

I realise that Liferay has been investing in developing a non-standard OSGI version of portlets. Dont know the reasons (performance? client captivity? ease of deployment?), and that in 7.1 several notions appearing in the standard have been provided for Liferay MVC Portlets in non standard way (such as commands) instead of working on the standard itself. 

So first, this is entirely incorrect.  Liferay 7 still supports the exact same portlet wars that it always has.  You can absolutely create a portlet war that is JSR-168 or JSR-286 compliant, bundle as a war and deploy to Liferay.

This is true for both 7.0 as well as for 7.1.

As to Liferay's investment in OSGi, it was necessary.  The 6.1 and 6.2 monoliths were too large and too hard to introduce change as even small changes caused ripple effects across the entire platform.  Larger changes like those needed for cloud, for Analytics Cloud and Emporio would have been extremely difficult to have implemented into the monolith; they likely wouldn't have happened at all.

The new modular architecture will allow Liferay to speed up the development and release cycles because changes are isolated and tested at module scope instead of at the platform level.

All of that said, you are not required to use OSGi in your portlet development.  Static util classes are still there, portlet wars are still there, nothing is preventing you from adhering to a standard which nobody really adhered to anyway.  Have you seen a pure 286 portlet anywhere?  No.  Not on Websphere, not on Liferay, not anywhere. The reality is that the spec defines a good way to build small apps that generate HTML fragments for aggregation by a portal platform, but they offer nothing in the way of the features and functionality that is provided by the portal vendors.

Websphere portlets are no different.  A good websphere portlet is decorated with IBM-specific goodness to take advantage of features and functionality provided by the system. Liferay is no different.

Iñaki Paz Rey:

Anyway, Lets wait then for GA2! Really looking forward to it, and expecting to be able to develop standard annotated portlets with CDI and no XML at all. 

Again, this is available today.  Maybe not by CDI, but you can use Spring Portlet MVC to build out your portlets, with dependency injection and leveraging Spring's annotations to avoid XML.  And you can package this up in a portlet war and deploy it to Liferay 6, Liferay 7.0 and Liferay 7.1.

Now since you really don't seem to understand any of the things you actually tried to claim, I'm sorry but you're coming off as merely a troll instead of someone trying to have an honest discussion about what is going on in the platform.