io.grpc.reflection.testing is available under which gradle dependency - grpc

import io.grpc.reflection.testing.AnotherDynamicServiceGrpc;
import io.grpc.reflection.testing.AnotherReflectableServiceGrpc;
import io.grpc.reflection.testing.DynamicReflectionTestDepthTwoProto;
import io.grpc.reflection.testing.DynamicServiceGrpc;
import io.grpc.reflection.testing.ReflectableServiceGrpc;
I am trying to import above classes for writing unit tests for server reflection & have added below gradle dependencies -
testImplementation group: 'io.grpc', name: 'grpc-testing', version: '1.51.0'
testImplementation group: 'io.grpc', name: 'grpc-protobuf', version: '1.51.0'
testImplementation group: 'io.grpc', name: 'grpc-core', version: '1.51.0'
but it is still not showing up. Which gradle dependency is required for them?

Those classes are stubs that are generated at build time from proto files in the gRPC services sub-project. This means there is no place you can directly import them from. For your testing you can either define your own test services or you can base them off the ones used by services. I recommend using your own proto package names though.

Related

Meteor Tabular errors on initialization

I'm following along the guide to setup Meteor Tabular v2.1.2 (guide). I have added the package and installed the theming packages. I'm using Meteor v2.8.0 and the project is a Blaze-based project.
In client/main.js, I set up the library as instructed.
import { $ } from 'meteor/jquery';
import dataTablesBootstrap from 'datatables.net-bs';
import 'datatables.net-bs/css/dataTables.bootstrap.css';
import "../imports/ui/body";
dataTablesBootstrap(window, $);
Now when I go to the browser, there is this error:
Can anyone help me on this?
So after serious debugging , I discovered it is enough to just import the DataTable module as such after installing it with npm
import { $ } from 'meteor/jquery';
import 'datatables.net-bs';
import 'datatables.net-bs/css/dataTables.bootstrap.css';
import "../imports/ui/body";
// You don't need the code previously here .
You can now setup you DataTable as such
$(element).DataTable(//Your config object)

Referencing external JAR from JavaFX Project

I'm trying to reference a set of APIs from my JavaFX project:
import jakarta.ws.rs.client.Client;
import jakarta.ws.rs.client.ClientBuilder;
import jakarta.ws.rs.client.WebTarget;
import jakarta.ws.rs.core.GenericType;
import jakarta.ws.rs.core.Response;
These APIs are available in this dependency:
<dependency>
<groupId>jakarta.ws.rs</groupId>
<artifactId>jakarta.ws.rs-api</artifactId>
<version>3.0.0</version>
</dependency>
Therefore, I have added the jakarta.ws.rs-api in my project's module-info.java :
module com.example.javafx {
requires javafx.controls;
requires javafx.fxml;
requires org.controlsfx.controls;
//External API
requires jakarta.ws.rs-api;
opens com.example.javafx to javafx.fxml;
exports com.example.javafx;
}
However, it seems incorrect: "Module directive expected" for "jakarta.ws.rs-api".
Should I use a different format to specify the external dependency?
Thanks
You must use the module name after requires.
The dash is not a allowed character for module names, just like for package name.
You can obtain the name of a module bundled in a jar file with:
jar --describe-module --file jakarta.ws.rs-api-3.1.0.jar
which gives jakarta.ws.rs

JFrog REST api client app fails to build with missing org.apache.commons.* packages

We have a Java app that was built using 2017 version of JFrog java services jar. Today I am trying to rebuild it using latest jfrog lib. I see that the new services jar doesn't have org.apache.* packages in it.
This is how I built jfrog services jar.
Downloaded 2.8.6 source zip and expanded it
Upgraded gradle to latest and ran "gradle clean build -x test -x javadoc"
Then copied services/build/lib/*services-2.8.6.jar ONLY to my project lib folder
When I try to build, I see so many compilation errors. The old lib was called something like artifactory-java-client-ning-services-1.2.0-all.jar.
How do I build one like it?
Update on 11/6/20 after Dror responses below:
I changed the build strategy to point to jcenter to download and create uber jar with all the dependencies with gradle file like below. I am still running into missing classes.
Below is one of those errors:
error: package org.jfrog.artifactory.client.ArtifactoryClient does not exist
import org.jfrog.artifactory.client.ArtifactoryClient.ProxyConfig;
In Netbeans IDE that I am using, I can expand each package in a jar and see the classes in it. I don't see anything under org.jfrog.artifactory.client package. That is strange.
My build.gradle:
group 'org.jftog.example'
version '1.0-SNAPSHOT'
apply plugin: 'java'
sourceCompatibility = 1.13
repositories {
jcenter()
}
dependencies {
compile 'org.apache.commons:commons-collections4:4.4'
compile group: 'ch.qos.logback', name: 'logback-classic', version: '1.2.3'
testImplementation group: 'junit', name: 'junit', version: '4.12'
implementation 'org.jfrog.artifactory.client:artifactory-java-client-services:+'
implementation 'org.jfrog.artifactory.client:artifactory-java-client-api:+'
}
jar {
from {
configurations.runtimeClasspath.collect { it.isDirectory() ? it : zipTree(it) }
}
exclude 'META-INF/*.RSA', 'META-INF/*.SF','META-INF/*.DSA'
}
Update on Nov 10th 2020:
I found that the artifactory sdk changed and I was using stale classes. I fixed those references in my classes to use newer SDK counterparts and the issues were gone.
I ended up using following gradle file to build everything I needed:
group 'artifactory-client-sdk'
version ''
apply plugin: 'java'
sourceCompatibility = 1.8
buildDir="${rootDir}/../out/artifactory_client_sdk"
def signbridge_lib="${rootDir}/../libs"
jar.baseName = 'artifactory-client-sdk'
repositories {
jcenter()
}
dependencies {
implementation 'ch.qos.logback:logback-classic:1.2.3'
testImplementation group: 'junit', name: 'junit', version: '4.12'
implementation 'org.jfrog.artifactory.client:artifactory-java-client-services:+'
implementation 'org.jfrog.artifactory.client:artifactory-java-client-api:+'
}
jar {
from {
configurations.runtimeClasspath.collect { it.isDirectory() ? it : zipTree(it) }
}
exclude 'META-INF/*.RSA', 'META-INF/*.SF','META-INF/*.DSA','**/org/jfrog/example'
}
task copyJar(type: Copy) {
from jar // copies output of file produced from jar task
into "${signbridge_lib}"
}
build.finalizedBy copyJar
Thanks a lot to Dror for great pointers!
The sources of the Artifactory Java client can be found in the jfrog/artifactory-client-java GitHub repository.
The services module used to be built as an uber jar containing 3rd party dependencies. On Oct 2019 the build has changed to create a thin jar instead of an uber jar.
To solve you issue you can either:
Include the 3rd party dependencies of the service module when building you application
Revert the change in build.gradle and continue to build an uber jar
Instead of building from source, you can consume the artifact from jcenter where is it being published by JFrog. The artifacts are published together with Maven .pom files which contains all the required 3rd party dependencies (all of them are available in jcenter).
In addition, there is an example Github project which shows how to consume the client library using Maven or Gradle.

Corda Dependency Conflicts prevent calling Classloader when using quasar agent

This is a copy of my post on corda's github issues.
I'm trying to include an external dependency to one of the sample projects.
This dependency calls ClassLoader.defineClass, which exits with java.lang.ClassFormatError: Illegal UTF8 string in constant pool in class file org/apache/xerces/impl/xpath/regex/ParserForXMLSchema. The exception is identical to the one mentioned by this quasar issue which suggests it is caused by conflicting dependencies and when using the quasar agent.
After running a dependency report on the project, I could not only see some conflicts between the external library and Corda, but also within Corda itself. So far Gradle has been dealing with them through its transient dependency management. Here is an extract of the report:
+--- org.apache.jena:jena-core:3.6.0 <-external library
...
| \--- org.apache.jena:jena-base:3.6.0
...
| +--- commons-io:commons-io:2.6 <- external lib dependency
\--- net.corda:corda-node-api:2.0.0
...
+--- commons-beanutils:commons-beanutils:1.9.3 <- corda dependency
| +--- commons-logging:commons-logging:1.2
| \--- commons-collections:commons-collections:3.2.2
+--- org.apache.activemq:artemis-core-client:2.1.0
| +--- org.jgroups:jgroups:3.6.13.Final
| +--- org.apache.activemq:artemis-commons:2.1.0
...
| | +--- commons-beanutils:commons-beanutils:1.9.2 -> 1.9.3 (*) <- corda conflict
...
+--- commons-fileupload:commons-fileupload:1.3.3
| \--- commons-io:commons-io:2.2 -> 2.6 <- external lib conflict
...
And here is my root build.gradle:
buildscript {
ext.corda_release_version = '2.0.0'
ext.corda_gradle_plugins_version = '1.0.0'
ext.kotlin_version = '1.1.4'
ext.junit_version = '4.12'
ext.quasar_version = '0.7.9'
repositories {
mavenLocal()
mavenCentral()
jcenter()
}
dependencies {
classpath "org.jetbrains.kotlin:kotlin-gradle-plugin:$kotlin_version"
classpath "net.corda.plugins:cordformation:$corda_gradle_plugins_version"
classpath "net.corda.plugins:quasar-utils:$corda_gradle_plugins_version"
classpath "org.jetbrains.kotlin:kotlin-noarg:$kotlin_version"
}
}
repositories {
mavenLocal()
jcenter()
mavenCentral()
maven { url 'https://jitpack.io' }
maven { url 'https://ci-artifactory.corda.r3cev.com/artifactory/corda-releases' }
}
apply plugin: 'kotlin'
apply plugin: 'net.corda.plugins.cordformation'
apply plugin: 'net.corda.plugins.quasar-utils'
sourceSets {
main {
resources {
srcDir "config/dev"
}
}
test {
resources {
srcDir "config/test"
}
}
}
dependencies {
compile "org.jetbrains.kotlin:kotlin-stdlib-jre8:$kotlin_version"
testCompile "org.jetbrains.kotlin:kotlin-test:$kotlin_version"
testCompile "junit:junit:$junit_version"
cordaCompile "net.corda:corda-core:$corda_release_version"
cordaCompile "net.corda:corda-node-api:$corda_release_version"
cordaRuntime "net.corda:corda:$corda_release_version"
testCompile "net.corda:corda-node-driver:$corda_release_version"
compile "org.apache.jena:jena-core:3.6.0"
}
For reference, the function call from jena-core is a one-line ModelFactory.createDefaultModel() inside a JUnit test. At this point I'm using the minimal required Corda libraries to run other tests since more conflicts arise when compiling unused libraries.
An alternative approach would be to use quasar aot instead of the agent, but I'm new to Gradle let alone Ant, and I haven't been able to find / come up with an example.
Finally, I also tried upgrading ext.corda_gradle_plugins_version = '1.0.0' to 2.0.9 as suggested by the corda docs but gradle is unable to call cordaCompile after the upgrade, and I haven't been able to find any documentation on the plugins.
Edit: I noticed upgrading artemis-core-client from 2.1.0 to 2.4.0 would resolve corda-node-api's internal conflict as you can see here. As for commons-io, sadly commons-fileupload is on the latest version 1.3.3 which hasn't been updated since July '17
You need to shade your dependencies, as described here: How can CorDapps deal with transitive dependencies.
Background: What is shading?
Say corda depends on Guava version 1. It will use import statements of the type import com.google.guava.SpecialList, meaning that the class com.google.guava.SpecialList must be present in the classloader when Corda is run.
Now, suppose a developer is writing a CorDapp which uses Guava version 2 instead. When the CorDapp is run, both the Guava version 1 and Guava version 2 JARs will be on the classpath.
At runtime, Java will load all the JARs on its classpath. This means that it's undefined which copy of com.google.guava.SpecialList will be loaded. It depends on order, environment, Java version, etc. And it’s possible that 40% of version 1 will be loaded, whilst 60% of version 2 will be loaded.
If version 1 and 2 are compatible, this is not a problem. Either the CorDapp will use version 1, or the Corda runtime will use version 2. The real fun begins when the two versions are incompatible, because now the application might work in some circumstances, and fail in others – it’s a nightmare.
Shading gives us a way out of this problem. It allows us to re-package dependencies so that their package definitions no longer clash.
As part of the build process, a shade plugin is executed, which will append corda.dep to all classes referenced by Corda and rewrite the bytecode of the importing classes so that they reference the modified package, import corda.dep.com.google.guava.SpecialList.
This results in version 1 of Guava being bundled with the Corda JAR in its own namespace (corda.dep). Any CorDapps that also depend on Guava can now safely import this library and include it on their classpath without conflicting with the version used by Corda.
There is a Gradle plugin for shading called shadow. We would invoke this plugin as the last stage of the build which produces the Corda runtime jar.

meteor[1.3.1] - import node package with builtin module

I try to import node-rsa npm package to my project: "import NodeRSA from 'node-rsa';" but i get following error: Cannot find module 'crypto'.
crypto is a node builtin module, so its not installed over npm. Does that mean i can't use 'node-rsa' directly?
https://atmospherejs.com/planifica/node-rsa works without any problems.
planifica:node-rsa - "Browserified Node.js RSA library carefully packed for Meteor"
thanks

Resources