1

I was using DocuSign for the digital signature in Liferay 6.2, now we are migrating to Liferay 7.3 with Gradle workspace.

In MVC Portlet:

I tried with this compileOnly group: 'com.docusign', name: 'docusign-esign-java', version: '2.8.0', and got error like Unresolved requirement: Import-Package: com.docusign.esign.api.

and If I tried with this compileInclude group: 'com.docusign', name: 'docusign-esign-java', version: '2.8.0' then i got JAVA Heap space error at runtime. As you mentioned, I modified my UI module by referring to that link. my bnd. bnd file:

Import-Package:\
    **!com.sun.jersey.api.container,\
    !com.sun.jersey.api.core,\
    !com.sun.jersey.api.model,\
    !com.sun.jersey.server.impl.inject,\
    !com.sun.jersey.server.impl.model.method.dispatch.\
    ***

and also put an entry in build.gradle as like

**compileInclude group: 'com.docusign', name: 'docusign-esign-java', version: '2.8.0'**

after the module gets started it is immediately throwing exceptions like

FrameworkEvent ERROR org.osgi.framework.ServiceException: Exception in org.apache.felix.scr.impl.manager.SingleComponentManager.getService().

BundleComponentActivator : Unexpected failure enabling component holder.
rgore
  • 11
  • 2

1 Answers1

0

We use compileinclude when a dependency is not a non-OSGi JARs. Maybe it is your case.

Just to double check, take a look at this guide:

https://learn.liferay.com/dxp/latest/en/liferay-internals/fundamentals/configuring-dependencies/resolving-third-party-library-package-dependencies.html

As told in the guide, see if you find a new (osgi compatible) version of your dependency.

If not, you will have to use compileinclude. You will have to find why your app server is running out of memory. Here some things to check it out:

  1. Is there any memory leak?
  2. Is there more memory available to be reserved to your app server?
  3. What is the current JVM configuration for -xms and -xmx?
Marcel Tanuri
  • 21
  • 5