Details

    • Similar Issues:
      Show 5 results 

      Description

      Core portlets are great because they are bundled into the core and are thus always available. They are essentially the java.lang.* of portlets.

      Plugins are great because they are loosely coupled from the core, have their own development cycle, and can be installed or uninstalled on demand. But the drawback of plugins is that you cannot guarantee that they are always available.

      The use case for this is similar to "required" app on your smart phone. There are about a dozen or so apps on your smart phone (Maps, Stocks, etc.) that are still loosely coupled from the phone's operating system, have their own development teams, can even be updated separately from the operating system, but are guaranteed to exist on your smart phone because they cannot be ripped out.

      We now have that ability in Liferay.

      At deploy time, when we make the portal WAR, we first scan portal-impl/src/com/liferay/portal/deploy/dependencies/plugins1, plugins2... to plugins9.

      We scan those 9 directories, and write a wars.txt file in each directory based on the list of WAR files in those directories. We do this at deploy time because class loader scanning for files at runtime is not guaranteed in Java. This also means the required plugins are checked in like libraries in the portal source repository. I chose to do it this way instead of having the portal source repository build the latest plugins on demand because that would create a circular dependency for some application servers (e.g. Glassfish, WebSphere) that require an unexploded portal WAR. Plugins would require a fully built portal, but now a fully built portal WAR would require those plugins. It's also just cleaner and simpler if the portal does not depend on the plugins SDK for development.

      On startup, the portal will read the wars.txt files for those 9 levels and copy the plugin files that are packaged inside the main portal WAR into the auto deploy directory. They are deployed in the order of the levels. So level 1 is deployed first and level 9 is deployed last.

      In our current use case, only the "marketplace-portlet" is at level 1, and we have no other required plugins at the other levels. But if we did, we would put them in levels 2 and beyond.

      If a required plugin is not installed, the portal will automatically install it. If a required plugin is manually removed, the portal will reinstall it. Deployment of additional plugins is disabled until all required plugins are registered.

        Issue Links

          Activity

          Hide
          David Kubitza added a comment -

          Is it really 9 directories? Seeing this line, I'm not sure about it (without having a deeper look at the rest of the code): https://github.com/liferay/liferay-portal/commit/feeaf8d96240037b837982444756592c0b2b187c#diff-9d9fc131711c6de81ee8bed919f02f0fR48

          Furthermore I cannot find any documentation about this feature, just my own blog entry: http://blog.ancud.de/web/guest/home/-/blogs/global-plugin-dependencies

          Show
          David Kubitza added a comment - Is it really 9 directories? Seeing this line, I'm not sure about it (without having a deeper look at the rest of the code): https://github.com/liferay/liferay-portal/commit/feeaf8d96240037b837982444756592c0b2b187c#diff-9d9fc131711c6de81ee8bed919f02f0fR48 Furthermore I cannot find any documentation about this feature, just my own blog entry: http://blog.ancud.de/web/guest/home/-/blogs/global-plugin-dependencies

            People

            • Votes:
              1 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated:

                Development

                  Structure Helper Panel