Splitting Several Portlets found in a Single Plugin into their own Plugin

[Juan Ávila，修改在7 年前。]

Hello, I need to split a plugin that contains several portlets into several plugins (one per portlet).

The tricky part is that I need to do this and conserve each one of the original portletids. When the new portlets plugins are deploy we need to make sure that those portlets remain "the same" since we don't want to have to re-add/configure them in all the sites and pages again.

To clarify the situation:

1) We have a Plugin called SomePortlets-portlet, where we have defined 3 portlets: portletA, portletB, portletC. This results having the fallowing portletids:

- portletA_WAR_SomePortletsportlet
- portletB_WAR_SomePortletsportlet
- portletC_WAR_SomePortletsportlet

(And in tomcat we get webapps/SomePortlets-portlet)

2) When separating the portlets this is what we get (as expected):

- portletA_WAR_PortletAportlet
- portletB_WAR_PortletBportlet
- portletC_WAR_PortletCportlet

(And in tomcat we get webapps/PortletA-portlet, webapps/PortletB-portlet, webapps/ PortletC-portlet)

Now, we would like to get the same portletids from point 1), but I'm not sure if that's posible.

Some attempts:

1) Changed the project name for each plugin (PortletA-portlet, PortletB-portlet, PortletC-portlet) in build.xml to SomePortlets:

<project name="SomePortlets-portlet" basedir="." default="deploy">
	<import file="../build-common-portlet-test.xml" />
</project>

This works for having a single portlet deployed correctly (it keeps the same portlet id), but the problem comes when deploying other the other plugins since each will override the next given that they have the same webpp name: SomePortlets-portlet

2) Kept the change from point 1) and updated the recommended-deployment-context in liferay-pluing-package.properties:

recommended-deployment-context=PortletA/SomePortlets-portlet

I see that the liferay deployment process correctly creates the webapp in webapps/PortletA/SomePortlets-portlet, however it seems like tomcat does not load the app.

The logs shows Portlets for ....war copied successfully. Deployment will start in a few seconds but nothing more.

Please let me know if accomplishing something like this is posible. Thanks!

[David H Nebinger，修改在7 年前。]

Yeah, portlet ids help track back to their origins; trying to fake ids to look like the y came from one war when they come from multiples may have unknown consequences.

The big question is why they need to be split? I mean, often times I recommend joining related portlets into a single plugin to reduce load times, duplicated classes in multiple class loaders, duplicated spring beans across multiple wars, ...

In general it's a good thing, so i'm interested in what is driving them to be split apart, if you don't mind sharing...

One item you might consider - a service wrapper on PortletLocalService, specifically the getPortletById() methods. You could trap for your old portlet names like portletA_WAR_SomePortletsportlet and pass the old portlet name of portletA_WAR_PortletAportlet or vice-versa, depending upon what makes more sense. This way the code should be able to find all exising portlet ids and prefs, etc., without changing what the portal is doing.




Come meet me at the LSNA!

[JP A.，修改在7 年前。]

There are some reasons behind the idea of separating those portlets in particular, most of them related to maintenance, code clean up, and individual deployments (according to the processes of the client). I know this can be accomplished without separating them, but there is a lot of highly coupled, duplicated and messy code in the way, all of them as a product of bad practices. Separating them might give us some air to clean them up individualy. Some of those portlets might also be removed in the future, so a bit of anticipated refactoring now might help us later.

All that said, you are right. And I was just hoping that there was a way of accomplishing this a without any kind of hack. We will considere you suggestions.

Thank you

[David H Nebinger，修改在7 年前。]

Well you must realize that what you're asking for, the different treatment of how Liferay handles portlet ids, that in itself is a request for a hack.

I think the one that I outlined will be the only way to pull this off without really tearing into the core.





Come meet me at the LSNA!