Develop a common jar library for different liferay portlets - jar

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?

There are ways you can do this:
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/.
Create a simple Java project. Package it as a JAR file. Put the JAR file in the classpath of each and every portlet.
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.
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.

Related

How can you split scalajs cross-project modules (js, jvm, shared) into subprojects?

I'm trying to set up scalajs project using sbt, and since I will be including a "shared" module that will be used by both the jvm side of the project (server) and the js side (web client), I plan to use sbt-scalajs-crossproject. The problem is that I would like to separate part of the js code from the rest to publish as a library (all of the reusable js components). This would require splitting the js part of the project into multiple subprojects. Is this possible?
The best solution I have found is to put the reusable components in a separate scalajs subproject which is published as a distinct module. The rest of the code then goes into a cross-project which depends on the scalajs components project.

Vaadin Flow and external CSS (theme)

In Maven multi-module project with Vaadin Flow 14 how can I build a common/shared style/theme module and reuse/import in the web application module.
Which one I should use in the web application. The #StyleSheet which can handle external CSS, or the newer #CssImport? Or do I have to use some maven plugin to copy reosurces (CSS files) from the theme module into the web app module (into the frontend or resources folder)? Is there any examples out there for vaadin 14 multi-module theming?
Any hint would be great, thanks!
There are possibly many ways to do this. I would assume the simplest way is to have component sub-module in your project. I have example here
https://github.com/TatuLund/bookstore-flow-ee/blob/master/bookstore-starter-flow-my-component/src/main/java/com/vaadin/samples/HelloWorld.java
The component itself can include styles, etc.
What I am proposing to you is to use similar custom component as base-layout of your application that imports the needed styles etc.

Spring + Microservice + JBoss

We are planning to build an application which has multiple modules
(say [Common which contains Admin, Registration], License Module,
Stock Module ). We have planned to use Maven as our build tool
Each module acts like a separate folder(war) where in it has MVC layers in it. Main POM should encapsulate all the modules and form a war file.
If a customer doesn't need License Module, i can just unplug the settings and recreate a war file without much effort.
Now i am struggling to find proper example to build a hierarchy(project structure like above)
Could you please guide me on this ?
You can create a parent project then add the child projects as modules. You can easily comment or delete these modules before building the project.
Here is a basic example.
http://www.concretepage.com/build-tools/maven/parent-pom-child-pom-example
You can get a good idea about parent child maven projects from the following thread as well.
Maven: adding a reference to a parent pom project

How to add multiple AMP modules to alfresco-sdk?

I am new to alfresco-sdk. I am used to have old style AMP modules and then run ant script to combine them into alfresco WAR file.
I have followed tutorials of alfresco-sdk for
alfresco all in one
alfresco AMP
alfresco share
archetypes and it ran successfully.
I could not figure out if I have three different AMP modules, how can I combine them in one?
Say for example, currently I following AMP modules in my repo -
alfresco-DEF-AMP
alfresco-generic-AMP
alresco-ABC-AMP
What should I do such that when I give amp-to-war command, it takes customization from above three modules and puts then into alfresco WAR.
I think you should stick with using a seperate archetype alfresco (AKA repository) AMP for each of your existing modules.
By Running the alfresco SDK maven build with target mvn package on each module, will create an amp file for you. These amps can then be deployed to your alfresco instance (with apply_amps.bat), just like you probably are used to, with ant builds.
You don t have to execute the maven build via run.bat file, which starts alfresco with your module in an embedded container.
If you really want to combine them into one, I suppose you ll have to merge your code of the 3 modules into one module of type alfresco AMP, and still work the above way.
We can use alfresco All-in-one archetype for that.
We can use overlays to include our custom modules such as
alfresco-DEF-AMP
alfresco-generic-AMP
alresco-ABC-AMP
to generate single WAR file (alfresco/repo.war)
Below link is very useful
http://docs.alfresco.com/sdk2.1/concepts/alfresco-sdk-advanced-add-custom-amps.html

How to share jar within multiple portlets?

I'm using several jars in my portlets, for instance c3p0. Now I want to avoid to put the jars in every of my portlets lib folders. How can I share one jar file within multiple portlets? And how should I integrate them in the Eclipse IDE? Add an external jar or put them in one dedicated project and include them from there?
Another solution would be to put them under ../liferay-portal-<version>/tomcat-<version>/webapps/ROOT/WEB-INF/lib
If you place them here you can add the JAR as a dependency for your portlet in the portlets liferay-plugin-package.properties (if you're using Liferay Developer Studio or Liferay IDE then there's a nice GUI for this).
Then on deployment Liferay will copy the required JARS from ROOT/WEB-INF/lib to your portlets WEB-INF/lib
This I believe is the Liferay support mechanism for doing it, and doesn't require a restart because the JARs are copied to the portlets classpath on deployment.
One way I can think off is to put all of them in the global path.
For e.g. in Tomcat you could place them at ../liferay-portal-<version>/tomcat-<version>/lib/ext and then when you configure the server-runtime library in eclipse you will have these jars in your build-path.
This link may also help you decide, but it speaks for *-service.jar but I am not sure it would work other jars in any one portlet.

Resources