Develop a common jar library for different liferay portlets

Question

I need some utility classes that will be common for three different Liferay portlets so I will develop them in one project that should be shared for my portlets.

I am using Eclipse with Liferay IDE plugin and my question is what kind of project is that one that I need?

I mean is it a simple Java project or any kind of Liferay project?

Incur

Yes, a simple Java Project is fine, as long as you package into as a JAR. Then to place the JAR have a look at this question: #12349962 – Unsettled

Answer 1

There are ways you can do this:

1. Create a simple Java project. Package it as a JAR file. Put the JAR file in global class-path In case of tomcat the global class-path would be ../tomcat-7.0.27/lib/ext/.
2. Create a simple Java project. Package it as a JAR file. Put the JAR file in the classpath of each and every portlet.
3. Create a Liferay plugin-portlet using service-builder, put the utility classes in the service package so that the utility classes go in the [name-of-your-project]-service.jar. And then in the portletswhich would need these classes specify the propertyrequired-deployment-contexts=[name-of-your-project]inliferay-plugin-package.properties` of each of the portlet.
4. Create a Liferay plugin-portlet using service-builder, put the utility classes in the service package so that the utility classes go in the [name-of-your-project]-service.jar and then put the [name-of-your-project]-service.jar in the global class-path and remove it from the WEB-INF/lib of your portlet project so that it does not conflict.

Conclusion

• Use 1st-method if the code in utility classes does not depend in anyway on the Liferay API. But this would require a server restart everytime there is a change in the utility classes. Also the Utility classes could be used by Hooks since it is in the global classpath
• Use 2nd-method if the code in utility classes does not depend in anyway on the Liferay API. This would not require server restart. But any change in the utility classes would require you to build & deploy all the plugin-portlets which use this jar.
• 3rd-method: This has the same limitations or features as the 2nd-method, just that you can use Liferay API & your custom service API in the utility classes.
• 4th-method: This has the same limitations or features as the 1st-method, just that you can use Liferay API & your custom service API in the utility classes.

So here I have listed pros & cons for you to decide for yourself. I would love to know if there are more ways (& much cleaner) to do this in liferay from experts.

Beckerman

@Incur Your welcome. So can you kindly accept this as an answer so that this may also help others. Thanks – Beckerman