I am trying to add a native prebuilt shared library to my project in Android Studio. I am using the gradle-experimental:0.6.0-alpha5. However, whenever I try to add the prebuilt shared library to my application model, I get the following error:
Error:Cause:
org.gradle.api.internal.PolymorphicDomainObjectContainerConfigureDelegate
The library is added into the application model how it is described by the Google Gradle Experimental Guide:
repositories {
prebuilt(PrebuiltLibraries) {
binaries.withType(SharedLibraryBinary) {
sharedLibraryFile = file("/path_to_libs/${targetPlatform.getName()}/shared_lib.so")
}
}
}
android.sources {
main {
jniLibs {
dependencies {
library "shared_lib"
}
}
}
}
The crucial line is library "shared_lib". There is no error if I uncomment this line.
Since this is not working, I have also tried to use the guide from ph0b.com. They are using a different syntax for adding native shared libraries (I just left out the headers since I do not have a single directory including all headers):
repositories {
libs(PrebuiltLibraries) {
shared_lib {
binaries.withType(SharedLibraryBinary) {
sharedLibraryFile = file("/path_to_libs/${targetPlatform.getName()}/shared_lib.so")
}
}
}
}
android.sources {
main {
jni {
dependencies {
library "shared_lib" linkage "shared"
}
}
}
}
Nevertheless, this does not work as well. Android Studio does not copy my shared_lib to the apk file. Hence, I always get the following error:
java.lang.UnsatisfiedLinkError: dalvik.system.PathClassLoader [...] couldn't find "shared_lib.so"
Can anyone tell me how I can include native prebuild library into my project? I am using buildToolsVersion = '22.0.1' and compileSdkVersion = 22 as build parameters.
This one worked for me (0.6.0-beta6).
repositories {
prebuilt(PrebuiltLibraries) {
YourLib {
binaries.withType(SharedLibraryBinary) {
sharedLibraryFile = file("src/main/libs/armeabi-v7a/libYourLib.so")
}
}
}
}
android.sources {
main {
jniLibs {
dependencies {
library "YourLib"
}
}
}
}
Looks like they just forgot to mention the "YourLib {}" part around "binaries.withType".
Related
I am using the below configuration build.gradle
plugins {
id "com.google.protobuf" version "0.8.17"
id "java"
}
group "de.prerna.aws.tests"
version "1.0-SNAPSHOT"
repositories {
mavenCentral()
}
ext {
protobufVersion = "3.18.1"
}
dependencies {
implementation "com.google.protobuf:protobuf-java:$protobufVersion"
sourceSets {
main {
proto {
srcDir 'src/main/proto'
}
java {
// include self written and generated code
srcDirs 'src/main/java'
}
}
}
protobuf {
protoc {
artifact = 'com.google.protobuf:protoc:4.0.0-rc-2'
}
plugins {
grpc {
artifact = "io.grpc:protoc-gen-grpc-java:1.39.0"
}
}
generateProtoTasks.generatedFilesBaseDir = 'generated-sources'
generateProtoTasks {
all().each { task ->
task.plugins { grpc{} }
}
ofSourceSet('main')
}
}
Error
* What went wrong:
Execution failed for task ':processResources'.
> Entry Person.proto is a duplicate but no duplicate handling strategy has been set. Please refer to https://docs.gradle.org/7.2/dsl/org.gradle.api.tasks.Copy.html#org.gradle.api.tasks.Copy:duplicatesStrategy for details.
A variant of BParolini for build.gradle (Groovy DSL)
tasks.withType(Copy) {
filesMatching("**/*.proto") {
duplicatesStrategy = DuplicatesStrategy.INCLUDE
}
}
I could fix this problem by adding the following code to my build.gradle.kts:
tasks {
withType<Copy> {
filesMatching("**/*.proto") {
duplicatesStrategy = DuplicatesStrategy.INCLUDE
}
}
}
Extra info: I'm using Gradle 7.3-rc-3 and Java 17.
Unfortunately nobody explains reasons for this problem, so here is some of my explorations and guesses. Please correct me if you know more.
If found that following build script code causes this error:
proto { srcDir 'src/main/proto' }
If look inside "build/extracted-include-protos" directory, there are original .proto files copied into "build/extracted-include-protos/test" (but not into main).
My guess is that those auto-copied .proto files are originally uses as the only sources, but when adding "src/main/proto" source set we give some compiler tool second set of same files.
Removing this srcDir is not a good idea, because it required for IDEA to correctly open included .proto on Ctrl+click (otherwise it is opened extracted copies which is useless).
I'm currently working on project with both Scala and Java. And we want to rewrite some Scala code on Java. So when I've been starting rewrite my code I've faced with this issue.
CountryResponse.java:5: illegal start of type declaration
It seem like Scala couldn't compile Java's records introduced in JDK 16. I've made some research and found only this discussion on GitHub. Could someone suggest any workaround to compile Java's records?
I did try increase Scala version from 2.12.2 to 2.13.6 but problem wasn't solved.
We use Java 16, Scala 2.12.2 and Gradle 7.0.1 and also scala and java plugins for Gradle.
Also here my gradle's settings for compile both sources.
compileScala {
sourceCompatibility("16")
targetCompatibility("16")
}
sourceSets {
main {
java {
srcDirs = []
}
scala {
srcDirs = ['src/main/scala', 'src/main/java']
}
}
}
edit: update link to discussion
I tested with following project containing both Scala and Java 16 sources. The Scala and Java source depends on each other.
If your both Java and Scala sources depend on each other, then you will need to put those sources under common folder. Lets say main/jvm.
You can place all your Java records under main/java. This will work as long as your records don't have dependency on Scala code. Otherwise you will have to break this into multiple modules and micromanage according to the dependency graph.
Gradle version is 7.1, and this project builds and then runs successfully (both ScalaMain and JavaMain).
build.gradle
plugins {
id 'java'
id 'scala'
}
group 'org.example'
version '1.0-SNAPSHOT'
repositories {
mavenCentral()
}
compileScala {
sourceCompatibility("16")
targetCompatibility("16")
}
sourceSets {
main {
java {
srcDirs = ['src/main/java']
}
scala {
srcDirs = ['src/main/jvm']
}
}
}
dependencies {
implementation 'org.scala-lang:scala-library:2.13.6'
}
main/java/TestJavaRecord.java
public record TestJavaRecord(int i) {}
main/jvm/TestScalaClass.scala
class TestScalaClass(val i: Int, val testJavaRecord: TestJavaRecord) {}
main/jvm/TestJavaClass.java
public class TestJavaClass {
public int i;
public TestScalaClass testScalaClass;
public TestJavaClass(int i, TestScalaClass testScalaClass) {
this.i = i;
this.testScalaClass = testScalaClass;
}
}
main/jvm/ScalaMain.scala
object ScalaMain extends App {
val testJavaRecord = new TestJavaRecord(5)
val testScalaClass = new TestScalaClass(5, testJavaRecord)
val testJavaClass = new TestJavaClass(5, testScalaClass)
println(testJavaRecord.i)
println(testScalaClass.testJavaRecord.i)
println(testJavaClass.testScalaClass.testJavaRecord.i)
}
main/jvm/JavaMain.java
public class JavaMain {
public static void main(String[] args) {
TestJavaRecord testJavaRecord = new TestJavaRecord(5);
TestScalaClass testScalaClass = new TestScalaClass(5, testJavaRecord);
TestJavaClass testJavaClass = new TestJavaClass(5, testScalaClass);
System.out.println(testJavaRecord.i());
System.out.println(testScalaClass.testJavaRecord().i());
System.out.println(testJavaClass.testScalaClass.testJavaRecord().i());
}
}
This question was answered before but the chosen answer doesn't explain a lot for me on how this is doable on Gradle.
That and the fact that I can't comment on the solution to ask for more info forced me to make this question.
I have a Gradle project that has several modules available and I now want to set up the Javadoc task to combine the Javadoc comments of all the modules into a single location where I could browse it.
How would I now be able to do this using Gradle? I run Gradle 5.5 if the version is of any importance and I have the following things set in the build.gradle file:
allprojects {
ext {
// Convenience method to configure Javadoc
configureJavadoc = { Object jDocConfig ->
jDocConfig.options {
it.author()
it.encoding = 'UTF-8'
it.memberLevel = JavadocMemberLevel.PROTECTED
if (it instanceof StandardJavadocDocletOptions) {
def opt = it as StandardJavadocDocletOptions
opt.links(
"https://docs.example.com/java/"
)
if (JavaVersion.current().isJava9Compatible()) {
opt.addBooleanOption("html5", true)
opt.addStringOption("-release", "8")
}
if (JavaVersion.current().isJava11Compatible()) {
opt.addBooleanOption("-no-module-directories", true)
}
}
}
}
}
}
subprojects {
javadoc {
destinationDir = file("$rootDir/docs/")
configureJavadoc(it)
}
}
I was able to do it with:
def exportedProjects = [
":",
":module-a",
":module-b",
":module-c"
]
task allJavadoc(type: Javadoc) {
source exportedProjects.collect { project(it).sourceSets.main.allJava }
classpath = files(exportedProjects.collect { project(it).sourceSets.main.compileClasspath })
destinationDir = file("${buildDir}/docs/javadoc-all")
}
I would like to distribute a jar of a library I created with all my dependencies bundled inside. However I would like to avoid version conflicts of dependencies with the adopting project.
I think maven shade can do this but I could not find a way to do this with Scala / SBT. I found OneJar however from my experiments with it seems to work only for executables.
How could I achieve this?
Thanks!
You can do this with your own classloader.
The classLoader:
Write a class loader which loads class files from diferent classloader using a rewrite.
For example you could add library as a prefix to the classpath when fetching the resource.
I have created a classloader using this teqnuiqe.
https://github.com/espenbrekke/dependent/blob/master/src/main/java/no/dependent/hacks/PathRewritingClassLoader.java
It replaces the method findClass in URLClassLoader with one adding a prefix.
protected Class<?> findClass(final String name) throws ClassNotFoundException {
Class result;
try {
result = (Class)AccessController.doPrivileged(new PrivilegedExceptionAction() {
public Class<?> run() throws ClassNotFoundException {
// This is where the prefix is added:
String path = PathRewritingClassLoader.this.prefix + name.replace('.', '/').concat(".class");
Resource res = PathRewritingClassLoader.this._ucp.getResource(path, false);
if(res != null) {
try {
return PathRewritingClassLoader.this._defineClass(name, res);
} catch (IOException var4) {
throw new ClassNotFoundException(name, var4);
}
} else {
return null;
}
}
}, this._acc);
} catch (PrivilegedActionException var4) {
throw (ClassNotFoundException)var4.getException();
}
if(result == null) {
throw new ClassNotFoundException(name);
} else {
return result;
}
}
We also have to rewrite resource loading
#Override
public URL getResource(String name){
return super.getResource(prefix+name);
}
Here is how it is used:
_dependentClassLoader = new PathRewritingClassLoader("private", (URLClassLoader)DependentFactory.class.getClassLoader());
Class myImplementationClass=_dependentClassLoader.loadClass("my.hidden.Implementation");
Building your jar:
In your build you place all the library and private classes under your selected prefix. In my gradle build I have a simple loop collecting all the dependencies.
task packageImplementation {
dependsOn cleanImplementationClasses
doLast {
def paths = project.configurations.runtime.asPath
paths.split(':').each { dependencyJar ->
println "unpacking" + dependencyJar
ant.unzip(src: dependencyJar,
dest: "build/classes/main/private/",
overwrite: "true")
}
}
}
Proguard can rename packages inside jar and obfuscate code. It is a bit complicated but you can achieve you goal with it. sbt-proguard plugin is actively maintained
Also you can check answers from similar thread:
maven-shade like plugin for SBT
UPDATE:
from version 0.14.0 sbt-assembly plugin seemed to have shading ability
Have you tried sbt-assembly plugin? It has set of merging strategies in case of conflicts and has pretty much nice start guide.
I have read many similar questions where the reply is that the project structure is not ideal so my questions based on the following:
I have a main project (ProjA) which needs to include a second project (ProjB) which is not a child project. ProjB has various resource files which need to be copied in the distribution of ProjA.
build.gradle of ProjA
dependencies {
compile project(":ProjB")
}
distributions {
main {
baseName = "Something"
contents {
into('bin') { from jar.archivePath }
into('lib') { from configurations.runtime }
into('etc') {
from ('../../projb/src/main/webapp') // Fix me!
}
}
}
}
1.) Ideally ProjB should expose the location of the resource files through a property used by ProjA, how can this be done?
2.) Is this the correct way to do it as I have read alot about cross-project properties not being ideal - or should I be doing something completely different?
Don't know if it helps but it seems that the best way is to do it in the following way:
distributions {
main {
baseName = "Something"
contents {
into('bin') { from jar.archivePath }
into('lib') { from configurations.runtime }
into('etc') {
from project(':projB').file('src/main/webapp')
}
}
}
}
The path must be hardcoded in that case.
Second option might be specifying a project property - in general not a very good idea - and use in another project - there must be also evaluation order defined.
In projB
ext.resourcesDir = project.file('src/main/webapp2')
and in projA
evaluationDependsOn(':projB')
and:
distributions {
main {
baseName = "Something"
contents {
into('bin') { from jar.archivePath }
into('lib') { from configurations.runtime }
into('etc') {
from project(':projB').file('src/main/webapp')
from project(':projB').resourcesDir
}
}
}
}
Here's complete example.