I get this error. I m guessing one of the libraries is importing a sub-library with version 15.0.1 and that's how the error is intoduced. If I can find which library is doing that maybe I could handle the situation.
How can I identify which library is causing the import of a specific sub library like com.google.android.gms:play-services-ads-identifier:15.0.1 for example ?
You can exclude sub-libraries like so:
implementation(group: 'com.graphhopper', name: 'graphhopper-core', version: '0.10.alpha3') {
exclude group: 'com.google.protobuf', module: 'protobuf-java'
exclude group: 'org.openstreetmap.osmosis', module: 'osmosis-osm-binary'
exclude group: 'org.apache.xmlgraphics', module: 'xmlgraphics-commons'
}
Of course this is just an example. You'll have to apply it to your own case.
You can find what's in them by looking through the maven repo.
As an example:
https://mvnrepository.com/artifact/com.graphhopper/graphhopper-core/0.10.0
Let me know if this was what you were looking for.
Related
I'm trying to build a lib without the test files, as described here https://setuptools.pypa.io/en/latest/userguide/pyproject_config.html. In the pyproject.toml, I got:
[tool.setuptools.packages.find]
include = ['lib*']
exclude = ['^.*tests']
with this exclude pattern correctly matching the 3 last elements:
lib
lib.mod1
lib.mod2
lib.utils
lib.mod1.tests
lib.mod2.tests
lib.utils.tests
Yet, when I build with python -m build and install the resulting wheel, I still get the 3 test modules in the distribution. What am I doing wrong?
It looks like you're using regex syntax. But this is a glob/wildmatch pattern, not regex.
Try this:
[tool.setuptools.packages.find]
include = ['lib*']
exclude = ['lib*tests']
Apart from the unsupported regex syntax (see https://stackoverflow.com/a/72524001/1551810), exclude doesn't work if the test files are included in the source distribution (sdist), e.g. because there is a MANIFEST.in that includes them or because of the use of the setuptools-scm package (see also https://github.com/pypa/setuptools/issues/3260).
If the tests are to be excluded from the wheel, but included in the sdist, the solution is to explicitly disable include-package-data (the default is true):
[tool.setuptools]
packages.find.include = ['lib*']
packages.find.exclude = ['lib*tests']
include-package-data = false
I'm new to Liferay. For my first project, I need to create a module which uses a third party library.
This library was developed by a university and is not used very often, so it's not on any maven repo or anything. Therefore I copied it into my Liferay project and I'm trying to figure out how to solve the dependency issues.
I read countless thread entries and blogs, but I'm still a little bit confused.
I hope someone can point me in the right direction to fix my problem.
build.gradle of the module
dependencies {
compileOnly group: "com.liferay.portal", name: "com.liferay.portal.kernel", version: "2.0.0"
compileOnly group: "com.liferay.portal", name: "com.liferay.util.taglib", version: "2.0.0"
compileOnly group: "javax.portlet", name: "portlet-api", version: "2.0"
compileOnly group: "javax.servlet", name: "javax.servlet-api", version: "3.0.1"
compileOnly group: "jstl", name: "jstl", version: "1.2"
compileOnly group: "org.osgi", name: "osgi.cmpn", version: "6.0.0"
compile files('lib/openBIS-API-V3-16.05.7-r1522065804.jar')
}
settings.gradle
buildscript {
dependencies {
classpath group: "com.liferay", name: "com.liferay.gradle.plugins.workspace", version: "1.5.0"
classpath group: "net.saliman", name: "gradle-properties-plugin", version: "1.4.6"
}
repositories {
maven {
url "https://cdn.lfrs.sl/repository.liferay.com/nexus/content/groups/public"
}
}
}
apply plugin: "net.saliman.properties"
apply plugin: "com.liferay.workspace"
bnd.bnd
Bundle-Name: my-dbdisplayer-project
Bundle-SymbolicName: de.mpi.prototype.dbdisplayer
Bundle-Version: 1.0.0
Export-Package: \
de.mpi.prototype.dbdisplayer.constants,\
Conditional-Package: \
ch.*
Bundle-Classpath:\
.,\
lib/openBIS-API-V3-16.05.7-r1522065804.jar
-includeresource:\
lib/openBIS-API-V3-16.05.7-r1522065804.jar
Terminal output when I deploy the module with blade deploy
BUILD SUCCESSFUL
Total time: 1.768 secs
stop 505
update 505 file:/home/liferay/MPI/liferay-prototype/modules/my-dbdisplayer-project/build/libs/de.mpi.prototype.dbdisplayer-1.0.0.jar
start 505
org.osgi.framework.BundleException: Could not resolve module: de.mpi.prototype.dbdisplayer [505]
Unresolved requirement: Import-Package: ch.ethz.sis.openbis.generic.asapi.v3
Updated bundle 505
Instead of using -includeresource and configuring Bundle-ClassPath yourself, consider using the configuration compileInclude in your gradle.properties.
As many pointed out, you probably need also to provide the library containing the package ch.ethz.sis.openbis.generic.asapi.v3. You probably don't want/cannot provide it as a module and want to include it in your bundle, the same way you include openBIS-API.jar. It would be something like this:
compileInclude files('lib/openBIS-API-V3-16.05.7-r1522065804.jar')
compileInclude files('lib/openBIS-asapi.jar')
or even:
compileInclude fileTree(dir: 'lib', include: '*.jar')
Of course you need this other openBIS-asapi.jar which contains the missing package. If this package is nowhere to be found, perhaps you could put this in your bnd.bnd:
Import-Package: *;resolution:=optional
EDIT
I just found in http://svnsis.ethz.ch/repos/cisd/openbis_api/trunk that the package is already in openbis_api, but this has a lot of dependencies. See:
http://svnsis.ethz.ch/repos/cisd/openbis_api/trunk/build.gradle
http://svnsis.ethz.ch/repos/cisd/common/trunk/build.gradle
compileInclude should copy and configure all dependencies for you, but I foresee more classloading problems...
EDIT 2
These two blog entries by Dave Nebinger explain how to use dependencies in Liferay modules
https://liferay.dev/blogs/-/blogs/osgi-module-dependencies
https://liferay.dev/blogs/-/blogs/gradle-compile-vs-compileonly-vs-compileinclude
By the way, in the second blog entry, I found something which does not seem to be correct. It is written there that packages your java code use from a compileOnly dependency will not be listed as Import-Package manifest entries, but I have a project with a compileOnly dependency for which said entry was generated.
Your bundle imports the package ch.ethz.sis.openbis.generic.asapi.v3. This is because that package is a dependency of the code inside the bundle.
You need to install a bundle that exports the package ch.ethz.sis.openbis.generic.asapi.v3.
I will leave an example of an uber jar for you here, with multiple libs inside.
In bnd.bnd
Bundle-RequiredExecutionEnvironment: JavaSE-1.8
Import-Package: *
Export-Package: javax.mail.*;version=1.5.6,\
javax.activation; version=1.1.1,\
com.sun.activation.*; version=1.1.1,\
com.sun.mail.*;version=1.5.6
-snapshot: ${tstamp}
-dsannotations: *
-check: all
-includeresource: lib/activation.jar=activation-1.1.1.jar,\
lib/javax.mail.jar=javax.mail-1.5.6.jar,\
lib/javax.mail-api.jar=javax.mail-api-1.5.6.jar
Bundle-ClassPath: ., lib/activation.jar, lib/javax.mail-api.jar, lib/javax.mail.jar
I have two dependencies that use a same library but with different versions and I get NoMethodError. I am not sure how to solve it using gradle or anything else? Any help would be great
group 'com.hello'
version '1.0-SNAPSHOT'
apply plugin: 'java'
apply plugin: 'idea'
repositories {
mavenCentral()
mavenLocal()
}
dependencies {
compile 'org.slf4j:slf4j-log4j12:1.7.12'
compile group: 'org.apache.spark', name: 'spark-core_2.11', version: '2.0.1'
compile group: 'org.apache.spark', name: 'spark-streaming_2.11', version: '2.0.1'
compile group: 'org.apache.spark', name: 'spark-streaming-kafka-0-10_2.11', version: '2.0.1'
compile group:'org.apache.kafka', name: 'kafka-clients', version: '0.10.1.0'
compile group: 'com.datastax.spark', name: 'spark-cassandra-connector_2.11', version: '2.0.0-M3'
compile group: 'com.github.brainlag', name: 'nsq-client', version: '1.0.0.RC2'
compile group: 'com.google.code.gson', name: 'gson', version: '2.7'
}
task buildStreamingJar(type: Jar) {
if(project.hasProperty("jarname")) {
def fullyQualifiedPackageName = ""
def jarname = project.getProperty("jarname")
if (jarname.equalsIgnoreCase("SparkDriver1")) {
fullyQualifiedPackageName = "com.hello.streamprocessing.app.SparkDriver1"
}
if (jarname.equalsIgnoreCase("SparkDriver2")) {
fullyQualifiedPackageName = "com.hello.streamprocessing.app.SparkDriver2"
}
baseName = project.name + "-$jarname" + "-stream"
from { configurations.compile.collect { it.isDirectory() ? it : zipTree(it) } }
with jar
zip64 true
from sourceSets.test.output
manifest {
attributes 'Main-Class': fullyQualifiedPackageName
}
exclude 'META-INF/.RSA', 'META-INF/.SF', 'META-INF/*.DSA'
}
}
so what is happening here is that in my dependencies spark-core_2.11 uses
com.google.guava:14.0.1 and nsq-client uses com.google.guava:19.0
which is leading to the following error.
Exception in thread "main" java.lang.NoSuchMethodError: com.google.common.collect.Sets.newConcurrentHashSet()Ljava/util/Set;
at com.github.brainlag.nsq.NSQProducer.(NSQProducer.java:22)
at com.hello.streamprocessing.app.SparkDriver2.main(SparkDriver2.java:37)
I need to use this build.gradle file to build a FAT Uber jar so I can use it with spark-submit
Basically you can't really solve this, if either spark-core or nsq-client is using features of guava that or not present in one version or the other. You can run gradlew dependencies which will show you how gradle resolves the version conflict on guava. By default it will choose version 19.0 as its the newer version. Your best chance is to use versions of your libraries that are dependent on the same version of guava. That is either to downgrade nsq-client or upgrade spark-core if possible.
You can exclude the transitive dependency to guava like this:
dependencies {
...
compile (group: 'com.github.brainlag', name: 'nsq-client', version: '1.0.0.RC2') {
exclude group: 'com.google.guava', module: 'guava'
}
...
}
However this will only work if nsq-client is not relying on features only present in version 19.0 of guava as mentioned above.
Sadly this is a common problem especially with the guava library as it is used in nearly every project and the developers don't care a lot about a stable API of their library.
Your best bet is probably to try excluding guava from spark-core and give it a try and, if it's not working, to exclude it from nsq-client and give it a try. But even if it seems to be working at a first glance odds are good (or actually bad in your case), that you will run into similar problems during runtime of your application.
If the above is not working, you could still fork nsq-client and replace the problematic parts with something compatible to guava 14.0.1. I don't really like this option but if the developers of nsq-client are nice they might accept your change...
One of the dependencies lib is not being downloaded. Use the latest lib of both. Use can as well use this:
repositories {
mavenCentral()
}
configurations {
compile
}
dependencies {
compile 'dependency repo1'
compile 'dependency repo2'
}
task libs(type: Sync) {
from configurations.compile
into "$buildDir/libs"
}
This will help download both dependencies.
In my Android Studio project I have two subprojects/modules: an Android application (App1) and an Android library project (LibraryProject1). App1 depends on LibraryProject1. So far so good.
However, LibraryProject1, in turn, needs to import an AAR library to work properly.
So my Configuration is as follows:
App1 includes LibraryProject1
LibraryProject1 includes dependency.aar
Now, to include dependecy.aar I use the method detailed here:
How to manually include external aar package using new Gradle Android Build System
So basically in my build.gradle for LibraryProject1 I have:
repositories {
flatDir {
dirs 'libs'
}
}
dependencies {
compile (name:'dependency', ext:'aar') //my AAR dependency
compile fileTree(dir: 'libs', include: ['*.jar'])
compile 'com.android.support:appcompat-v7:22.1.1'
}
Obviously, I put my dependency.aar file in the libs directory of LibraryProject1
However, this doesn't work. It seems that the repository added by LibraryProject1 is completely ignored and the local "libs" folder is not included as a repository, causing compilation to fail.
If I add the repository from the App1's build.gradle it works, but I don't want to do that, it's LibraryProject1 that needs the AAR file, not App1.
How can I do this??
Well, I found a way, but since it's very "hacky" I'll leave the question open, in case anyone comes up with a better, "proper" solution.
Basically the problem is that the flatDir repository is ignored at compilation time if included from LibraryProject1's build.gradle script, so what I do is I use App1's build.gradle to "inject" the flatDir repository in LibraryProject1. Something like this:
//App1 build.gradle
dependencies {
//get libraryproject1 Project object
Project p = project(':libraryproject1')
//inject repository
repositories{
flatDir {
dirs p.projectDir.absolutePath + '/libs'
}
}
//include libraryproject1
compile p
}
This effectively allows LibraryProject1 to include the external AAR library without having App1 include it. It's hacky but it works. Note that you still have to put:
//LibraryProject1 build.gradle
repositories {
flatDir {
dirs './libs'
}
}
inside LibraryProject1's build.gradle otherwise, even if the project itself would compile fine, the IDE wouldn't recognize the types included in the AAR library. Note that the ./ in the path also seems to be important, without it the IDE still doesn't recognized the types.
I faced to the same issue, and I figure out it by putting all libraries on that depends LibraryProject1 in LibraryProject1/libs as a .jar.
I think that aar library cannot be linked to another aar library.
Hope that help you,
Best regards
I've been iterating on features in my first Gradle plugin. I determined early on that I needed commons-io, so I added a dependency on commons-io 2.4, being the latest version.
This has been going well for a while, with the build working from the command line, and no errors in Eclipse.
I just started trying to integrate some code that uses "FileUtils.write(File,String)". I didn't need that method before. I got everything un-redded in Eclipse, and then I tried a command line build.
This failed with errors like the following:
... error: cannot find symbol
FileUtils.write(serviceLoaderFile,
^
symbol: method write(File,String)
location: class FileUtils
This confused me. I went to the failing lines in Eclipse, and no issues were indicated. I navigated into the "write()" method, and it looked fine to me. I then ran my command-line build with "--debug" to get some clues.
When I found the "javac" line, I found that "$GRADLE_HOME\lib\commons-io-1.4.jar" (where "GRADLE_HOME" is just my Gradle 2.3 distribution) was in the classpath BEFORE my dependency jar. I then inspected the code in the 1.4 jar, and I determined that the "FileUtils" class in that version didn't have a "write" method.
What am I supposed to do about this?
Update:
I suppose it's likely my "dependencies" block would be useful, which is this:
dependencies {
compile ("org.codehaus.groovy:groovy-all:2.3.9")
compile gradleApi()
compile "org.opendaylight.yangtools:yang-parser-impl:0.7.0-SNAPSHOT"
compile "org.opendaylight.yangtools:binding-java-api-generator:0.7.0-SNAPSHOT"
compile "org.opendaylight.yangtools:binding-generator-api:0.7.0-SNAPSHOT"
compile "org.opendaylight.yangtools:binding-generator-impl:0.7.0-SNAPSHOT"
compile "org.opendaylight.controller:yang-jmx-generator:0.3.0-SNAPSHOT"
compile "commons-io:commons-io:2.4"
testCompile("org.spockframework:spock-core:1.0-groovy-2.3") {
exclude group: "org.codehaus.groovy"
}
I tried commenting out the "gradleApi" reference, and that had no effect. I also tried adding an "exclude" for commons-io associated with the "groovy-all" reference, but that also didn't appear to make any difference.
}
You probably added gradleApi() under dependencies {} block - see the docs. The problem is that it ships all dependencies gradle requires - including commons-io in version 1.4 - see the extract below:
[opal#opal-mac-2]~/.gvm/gradle/current/lib % pwd
/Users/opal/.gvm/gradle/current/lib
[opal#opal-mac-2]~/.gvm/gradle/current/lib % ll commons-io-1.4.jar
-rw-rw-r-- 1 opal staff 109043 23 gru 13:17 commons-io-1.4.jar
[opal#opal-mac-2]~/.gvm/gradle/current/lib %
You probably added version 2.4 separately and that's why conflict occurred. You can also run
gradle dependencies
to view the full dependency tree and verify the problem.
There's no possibility to exclude a transitive dependency from gradleApi().
The solution to this required adding the following block to the "sourceSets" block:
main {
compileClasspath = configurations.compile.minus files("$gradle.gradleHomeDir/lib/commons-io-1.4.jar")
}
This is pretty simple, but I wish there was a cleaner solution for this. I'm not sure what that would look like.