Separating portlets from framework

[Hitoshi Ozawa, modificado 11 Anos atrás.]

Liferay portlets are fun to play around but I really don't have any actual user using them. I know that some users are actually using them, so I won't recommend deleting them. It would be nice however, if the framework is separated from what's on top of it.

This is because liferay offers a nice customization techniques using hooks, theme, and ext plugins and now security patches, but I really don't need them for things on top of the framework. By framework, I mean service builder and things underneath it. These, I usually don't touch, but the other things on top, I have to do some modifications or disable them so I can't apply patches to it.

This will make the system easier to customize and to maintain.

[David H Nebinger, modificado 11 Anos atrás.]

I both agree and disagree

On one hand it would be great if many of the really unused portlets were not part of the core (i.e. the categories finance, entertainment, shopping, Hello samples, and some from tools).

On the other hand, some of the portlets must be considered part of the core, i.e. the categories content management, social, news, wiki, collaboration, iframe and web proxy from samples and some from tools, are (IMHO) necessary.

That said, separating them out would mean separate wars for them, and that increases the size of your application container's memory and resource consumption.

Maybe deploy the categories as separate portlet packages, finance would have all of the finance portlets (currency converter, loan calculator), etc. Then administrators could choose whether to deploy the whole category or not...

Or a better idea would be some kind of 'roll your own portlet package' scenario. Liferay core comes separately, then on the Liferay site you check the core portlets you want to include. Then dynamically a single deployable war containing the selected portlet plugins is created, and it has all of the necessary stuff for the selected portlets to work based upon your selection...

Yeah, I like that. I as the user would indicate that I wanted blogs or I didn't. Later on I could change my mind and re-create the 'portlet package' to re-deploy over my older package and I can add/remove them that way...

Nice

[Hitoshi Ozawa, modificado 11 Anos atrás.]

Maybe deploy the categories as separate portlet packages, finance would have all of the finance portlets (currency converter, loan calculator), etc. Then administrators could choose whether to deploy the whole category or not...

Or a better idea would be some kind of 'roll your own portlet package' scenario. Liferay core comes separately, then on the Liferay site you check the core portlets you want to include. Then dynamically a single deployable war containing the selected portlet plugins is created, and it has all of the necessary stuff for the selected portlets to work based upon your selection...

Yeah, I like that. I as the user would indicate that I wanted blogs or I didn't. Later on I could change my mind and re-create the 'portlet package' to re-deploy over my older package and I can add/remove them that way...

This should be possible with ant or maven. Users are responsible for modifying the CE version so it really doesn't matter too much, but for the EE version, I hope they would really do this because I think it'll greatly increase the quality of an installation. I can't "unpackage" these default portlets using ext-plugins. Deleting them out may cause error during a patch or they may come back in after an upgrade.

They're good for a bundled demo package, but I don't think everybody is actually using them all in production system.

[David H Nebinger, modificado 11 Anos atrás.]

Well, there is the issue of the imports in the JSP pages...

All of the portlets do imports basically back to /html/common/init.jsp...

If you broke them out to separate plugins, I don't think you can do imports like that anymore..

And it would also blow out the idea of hooking the portlets. The usability of jsp hooks would go down significantly...

[Ray Augé, modificado 11 Anos atrás.]

Hey guys,

There is a undertaking to implement a better modularity layer which uses osgi. It's my hope that we'll be able to break some less used parts out into plugins.

Ideally I'd love to see a very compact yet functional core, without the massive burden of code it has now. However, we would make sure that there is an avenue for doing the kinds of customizations you are doing now on parts of the portal which get broken out, including actually extending some of those features out which don't currently exist for plugins.

e.g. OSGi has a very nice feature called "Bundle Fragments" which allows you to define a "parasitic" artifact that latches onto any existing bundle (OSGi's modularity unit, basically a fancy jar/war with extra metadata). These fragments can provide extra functionality to the "host" bundle, such as perhaps, custom jsps, classes, libraries, access to extra services, or whatever, all in a runtime enabled and manageable lifecycle.

Also, regarding the increase in the memory utilization. If properly done, we can actually solve much of the re-usablility issues that occur now with regular webapps, such as not being able to share the same jars without promoting those to the shared classpath of the app server which is often impossible, or just a huge pain when it comes to heavy frameworks like JSF or Spring. Add to that several different versions of the same libraries and you soon find yourself in a hole you want to frantically get yourself out of. OSGi solves these issues without having to touch the shared classpath.

Thoughts?