Fórum

Gradle Dependency Issues

thumbnail
Liferay Dev, modificado 6 Anos atrás.

Gradle Dependency Issues

Junior Member Postagens: 81 Data de Entrada: 17/05/15 Postagens Recentes
Hi,

We are trying to use external JARs for our custom portlet development and after adding dependency in Gradle file, we are getting exception and the package is not starting.
We are getting "Unresolved requirements; import-pakage <package path>" for the classes being used inside the jar. Then the team is adding the all the classes in bnd file to resolve them. But it is killing too much time. Is there any better way to manage external dependency?

The following non-working example is for Apache POI:

Included resources in build.gradle file
compileOnly group: 'org.apache.poi', name: 'poi-ooxml', version: '3.15'
compileOnly group: 'junit', name: 'junit', version: '4.10'
compileOnly group: 'org.apache.poi', name: 'poi-scratchpad', version: '3.15'
compileOnly group: 'org.apache.poi', name: 'poi', version: '3.15'
compileOnly group: 'org.apache.xmlbeans', name: 'xmlbeans', version: '2.4.0'

Added in bnd.bnd file
@poi-ooxml-[0-9]*.jar!/org/apache/poi/xssf/usermodel/*,\
@poi-ooxml-[0-9]*.jar!/org/apache/poi/*,\
@junit-[0-9]*.jar!/junit/framework/*,\
@junit-[0-9]*.jar!/junit/textui/*,\
@junit-[0-9]*.jar!/junit/runner/*,\
@poi-scratchpad-[0-9]*.jar!/org/apache/poi/*,\
@poi-[0-9]*.jar!/org/apache/poi/*,\
@xmlbeans-[0-9]*.jar!/org/apache/xmlbeans/*,\

As per the following link https://web.liferay.com/en/web/user.26526/blog/-/blogs/osgi-module-dependencies,
We also tried like download , keep the jar file in lib folder and mention the path in bnd file even though our problem was not fixed.
Ex: -includeresource:\
lib/itext.jar=itext-1.4.8.jar,\
lib/commons-lang.jar=commons-lang=[0-9]*.jar



Thanks.
thumbnail
David H Nebinger, modificado 6 Anos atrás.

RE: Gradle Dependency Issues

Liferay Legend Postagens: 14914 Data de Entrada: 02/09/06 Postagens Recentes
Liferay Dev:
Then the team is adding the all the classes in bnd file to resolve them.But it is killing too much time. Is there any better way to manage external dependency?


No.

Ultimately your bundle is declaring that it has a certain list of dependencies before it can start. OSGi is dutifully checking and finding that it cannot resolve the dependencies so the bundle can't start. It is what it is.

The following non-working example is for Apache POI:


Oh, another one. I have no idea why everyone has so many problems getting POI working...

Included resources in build.gradle file
compileOnly group: 'org.apache.poi', name: 'poi-ooxml', version: '3.15'
compileOnly group: 'junit', name: 'junit', version: '4.10'
compileOnly group: 'org.apache.poi', name: 'poi-scratchpad', version: '3.15'
compileOnly group: 'org.apache.poi', name: 'poi', version: '3.15'
compileOnly group: 'org.apache.xmlbeans', name: 'xmlbeans', version: '2.4.0'

Added in bnd.bnd file
@poi-ooxml-[0-9]*.jar!/org/apache/poi/xssf/usermodel/*,\
@poi-ooxml-[0-9]*.jar!/org/apache/poi/*,\
@junit-[0-9]*.jar!/junit/framework/*,\
@junit-[0-9]*.jar!/junit/textui/*,\
@junit-[0-9]*.jar!/junit/runner/*,\
@poi-scratchpad-[0-9]*.jar!/org/apache/poi/*,\
@poi-[0-9]*.jar!/org/apache/poi/*,\
@xmlbeans-[0-9]*.jar!/org/apache/xmlbeans/*,\

As per the following link https://web.liferay.com/en/web/user.26526/blog/-/blogs/osgi-module-dependencies,
We also tried like download , keep the jar file in lib folder and mention the path in bnd file even though our problem was not fixed.
Ex: -includeresource:\
lib/itext.jar=itext-1.4.8.jar,\
lib/commons-lang.jar=commons-lang=[0-9]*.jar


I have a working POI portlet, this is the build.gradle file I use:

dependencies {
    compileOnly group: "com.liferay", name: "com.liferay.application.list.api", version: "2.0.0"
	compileOnly group: "com.liferay.portal", name: "com.liferay.portal.kernel", version: "2.6.0"
	compileOnly group: "com.liferay.portal", name: "com.liferay.util.taglib", version: "2.5.0"
	compileOnly group: "javax.portlet", name: "portlet-api", version: "2.0"
	compileOnly group: "javax.servlet", name: "servlet-api", version: "2.5"
	compileOnly group: "jstl", name: "jstl", version: "1.2"
	compileOnly group: "org.osgi", name: "org.osgi.core", version: "5.0.0"
	compileOnly group: "org.osgi", name: "org.osgi.service.component.annotations", version: "1.3.0"
    compileOnly group: "com.liferay", name: "com.liferay.frontend.taglib", version: "2.0.0"
	compileOnly group: "com.liferay", name: "com.liferay.portal.upgrade", version: "2.3.0"
    compile 'biz.aQute.bnd:biz.aQute.bndlib:3.1.0'
    compile 'com.liferay:com.liferay.portal.configuration.metatype:2.0.0'
    compile group: 'commons-lang', name: 'commons-lang', version: '2.6'
    compile group: 'org.apache.poi', name: 'poi', version: '3.11'
    compile group: "com.liferay", name: "com.liferay.frontend.taglib", version: "2.0.0"
    compile group: "com.liferay", name: "com.liferay.item.selector.api", version: "2.0.0"
    compile group: "com.liferay", name: "com.liferay.item.selector.criteria.api", version: "2.0.0"
}


And the only thing I have in my bnd.bnd file relative to class loading is:

Import-Package:\
	javax.portlet;version='[2.0,3)',\
	javax.servlet;version='[2.5,4)',\
	*
-includeresource:\
  lib/poi.jar=poi-3.11.jar

Bundle-ClassPath:\
  .,\
  lib/poi.jar


I don't have the other dependencies on scratchpad or ooxml or xmlbeans, only you know if you really have those dependencies or not.

NOTE: OSGi does not respect "sloppy" or "lackadaisical" development. If your team is struggling, it is because there is not enough care being applied to selection of dependencies and/or research on what transitive dependencies are incurred by each.



I often use, as an example, a case where I was using XStream to handle XML marshaling. By selecting XStream, I had to understand the dependencies of it, so I went to http://mvnrepository.com/artifact/com.thoughtworks.xstream/xstream/1.4.10 to review the list of compile dependencies. If it wasn't listed as optional, I knew I needed to account for it in the bnd process lest I would immediately run into unresolved references.

For the optional dependencies, I had to know or research what capability the dependencies provided and whether I was going to need it. One of the optional dependencies is Joda Time, and knowing that's a time conversion and processing library and my XML did not have any time/date information, so those would be handled using the !package syntax in the Include-Package directive in the bnd.bnd file.

And for each dependency that I was including, I had to repeat this process on those to determine what their dependencies are and deal with those. Wash, rinse repeat until you understand and have dealt with all of your dependencies.

This process is necessary so you don't suffer through the "add dep or ignore package to code, build, deploy, get next unresolved ref" cycle. When you do a good job at it, it will probably not translate into a good start on first deployment, there will still probably be a few unresolved refs. But since you've done all of your research, you know how to apply the above policy to analyze the dependency and resolve it appropriately.





Come meet me at Devcon 2017 or 2017 LSNA!