1. Home
  2. Development
  3. RE: Including Third Party jars as a Separate OSGI Module

RE: Including Third Party jars as a Separate OSGI Module

thumbnail
Aravinth Kumar, modified 5 Years ago.
Including Third Party jars as a Separate OSGI Module
Regular Member Posts: 152 Join Date: 6/26/13 Recent Posts
Hi All,
I m using liferay 7.2 DXP. I have more third party dependencies like jsoup, apache cxf used in multiple modules.  As of now we are directly including it in the pom.xml of each module. In future, we are planning to create a separate osgi module which consists of all third party dependencies and include them in all other normal modules (It has both OSGI Module and Spring MVC Portlet).I m trying to follow the link, https://liferay.dev/blogs/-/blogs/osgi-module-dependencies to make the module as uber module but getting Caused by: java.lang.NoClassDefFoundError error in runtime.  Please guide me if I need to do anything else. 
Thanks in Advance.


Regards,Aravinth
thumbnail
Olaf Kock, modified 5 Years ago.
RE: Including Third Party jars as a Separate OSGI Module
Liferay Legend Posts: 6441 Join Date: 9/23/08 Recent Posts
Aravinth Kumar:

I m using liferay 7.2 DXP. I have more third party dependencies like jsoup, apache cxf used in multiple modules.  As of now we are directly including it in the pom.xml of each module. In future, we are planning to create a separate osgi module which consists of all third party dependencies and include them in all other normal modules (It has both OSGI Module and Spring MVC Portlet).I m trying to follow the link, https://liferay.dev/blogs/-/blogs/osgi-module-dependencies to make the module as uber module but getting Caused by: java.lang.NoClassDefFoundError error in runtime.  Please guide me if I need to do anything else.
You're not winning a lot by combining them all into a single bundle. Check if some of them are bundles already and then just deploy them independently. You might also find OSGi-ified dependencies in the servicemix repositories.
Other than that, reading the description above to the letter: You're doing something, see an error and wonder if you need to do something else. (Sorry for the sneaky italics) - Based on the description, I'd say: Yes, you'll need to do something else, but as we don't know what you're doing, it's hard to say what to do differently.
thumbnail
Aravinth Kumar, modified 5 Years ago.
RE: Including Third Party jars as a Separate OSGI Module
Regular Member Posts: 152 Join Date: 6/26/13 Recent Posts
Hi Olaf,
Thank you for the response.  We have kept Apache Service Mix/Eclipse Orbit as last option as we have many third party jars and its a migration project from 6.2 Spring MVC. Apache Service Mix works perfectly.

I followed the below way.

1.Created a OSGI module "Parent" and include all the jars. Used Include-Resource: in the bnd.bnd file. 
2.Generated jar contains all the classes of the third party jar.
3. Included that jar in Child Spring MVC portlet as with provided scope but getting "java.lang.NoClassDefFoundError" in runtime.

Regards,
Aravinth
thumbnail
Olaf Kock, modified 5 Years ago.
RE: Including Third Party jars as a Separate OSGI Module
Liferay Legend Posts: 6441 Join Date: 9/23/08 Recent Posts
Aravinth Kumar:

1.Created a OSGI module "Parent" and include all the jars. Used Include-Resource: in the bnd.bnd file. 
2.Generated jar contains all the classes of the third party jar.
3. Included that jar in Child Spring MVC portlet as with provided scope but getting "java.lang.NoClassDefFoundError" in runtime.
Not knowing what "all the jars" are and for which class you get the "NoClassDefFoundError", you're most likely missing either the class that the error message is complaining about, or one of its dependencies: The class might not load if it references another missing class, e.g. in one of its fields.
thumbnail
David H Nebinger, modified 5 Years ago.
RE: Including Third Party jars as a Separate OSGI Module
Liferay Legend Posts: 14933 Join Date: 9/2/06 Recent Posts
Aravinth Kumar:

We have kept Apache Service Mix/Eclipse Orbit as last option as we have many third party jars and its a migration project from 6.2 Spring MVC. Apache Service Mix works perfectly.

I followed the below way.

1.Created a OSGI module "Parent" and include all the jars. Used Include-Resource: in the bnd.bnd file. 
2.Generated jar contains all the classes of the third party jar.
3. Included that jar in Child Spring MVC portlet as with provided scope but getting "java.lang.NoClassDefFoundError" in runtime.



Eeek! Run away, run away!


Seriously though, what you are doing is a nightmare waiting to happen. If your stuff is working as a portlet war in 6.2, just keep it as a portlet war for 7.x. Spring, service mix, orbit, etc are all going to introduce some heavy dependencies and transient dependencies that will be difficult to manage from a build perspective but also a catastrophe waiting to happen with runtime class loader conflicts.

Keeping them as a portlet war will help to contain the dependencies and not bleed them into the OSGi container where they can really muck up the works.

You save little if anything trying to turn them into globally available dependency packages and risk disruption of the portal by conflicting with packages and libraries it provides and/or uses.
thumbnail
Aravinth Kumar, modified 5 Years ago.
RE: Including Third Party jars as a Separate OSGI Module
Regular Member Posts: 152 Join Date: 6/26/13 Recent Posts
Hi David, 
Thanks for your inputs. We have tried to deploy the war files in liferay dxp and found that deployment time is more due to external third party dependencies and war file size. 
Anyway the modules works fine without any issue after deployment.
To reduce the deployment time, we have planned of moving the third party dependencies as a separate module and we were also able to achieve to some extent with few small third party jars like jsoup with/without transitive dependencies. 
Also we have tried of using some liferay  provided modules by checking com.liferay.portal.bootstrap.jar\META-INF\system.packages.extra.mf file and able to achieve to some extent.

Regards,
Aravinth