Gradle version of quickstart-java template

hi all,

our shop does not use Maven i.e. we are totally a Gradle shop, would like to figure out away of creating a Java gradle template, preferably a Groovy quickstart template that uses Gradle as its build mechanism

Maybe Groovy is too much ask although quite popular but Gradle is practically ubiquitous .

Any hope ?

thanks

-Charles

I use this one (stripped down):

buildscript {
    repositories {
        mavenCentral()
    }
    dependencies {
        classpath("org.springframework.boot:spring-boot-gradle-plugin:2.3.3.RELEASE")
    }
}

plugins {
    id 'org.springframework.boot' version '2.3.3.RELEASE'
    id 'io.spring.dependency-management' version '1.0.10.RELEASE'
    id 'java'
    id 'idea'
}

group 'com.example'
version = '1.0.0'

sourceCompatibility = 11
targetCompatibility = 11

tasks.withType(JavaCompile) {
    options.encoding = 'UTF-8'
}

def daSdk = '100.13.55'

repositories {
    maven { url "https://digitalassetsdk.bintray.com/DigitalAssetSDK" }
    maven { url "https://repo.maven.apache.org/maven2" }
}

sourceSets.main.resources.includes = [ "**" ]

dependencies {

    implementation 'org.springframework.boot:spring-boot-starter'
    compile('org.springframework.boot:spring-boot-starter-web')
    testImplementation('org.springframework.boot:spring-boot-starter-test') {
        exclude group: 'org.junit.vintage', module: 'junit-vintage-engine'
    }
    compile group: 'com.daml.java', name: 'codegen', version:"${daSdk}"
    compile (group: 'com.daml.ledger', name: 'bindings-rxjava', version:"${daSdk}") {
        exclude(module: 'protobuf-lite')
    }
    implementation 'org.projectlombok:lombok'
    annotationProcessor 'org.projectlombok:lombok'
}

task dar(type: Exec) {
    commandLine 'daml', 'build'
}

task codegen(type: Exec) {
    commandLine 'daml', 'codegen', 'java'
}

perbergman:

def daSdk = '100.13.55'

Cool, i take it that’s the current release.
I was sniffing around maven central

also still quite new to this, I also assume the rx-bindings is a ledger api alternative to using a json/http binding.

I’ll note since possibly you can point me in the right direction , is that right now I’m trying to emulate the initial interactive tutorials and instead of using React I would use JavaFX, I believe that ledger api are built into the libs accessible to the React app, so can I achieve the same with the ledger rx-bindings ? or do I have to make json/http calls ?

Anyhow, thanks for the build file, it will definitely get me started.

Yes, 100.13.55 is the latest non-snapshot AFAIK for the java bindings AFAIK. Note that this is not the same as the daml SDK version, which is 1.11.1 right now.

The SDK for the ledger API is via Java/scala. For a React app you need to use the JSON API Service: HTTP JSON API Service — Daml SDK 1.11.1 documentation.

@perbergman That’s not quite right. The 100.* stuff was only used before SDK 1.0.0. Starting from that, the Java libraries have exactly the same version as the SDK. So the latest version is 1.11.1. You also no longer need Bintray, everything is published to Maven central. I highly recommend switching to a newer version.

The libraries changed name slightly.

1. com.daml.java:codegen is now com.daml:codegen-java but you shouldn’ t actually need a dependency on that at all. You only need the daml codegen java command which comes from your SDK installation and not from Maven.
2. com.daml.ledger:bindings-rxjava is now com.daml:bindings-rxjava.

Ah, thanks for the clarification. I should definitely update.

“If you have no problems, buy a goat.”

Per

great all, thanks , I will try to setup the build file.
To be clear, not interested in using React for the presentation but rather JavaFX , so therefore I guess all i need in the java ledger api

buildscript {
    repositories {
        mavenCentral()
    }
    dependencies {
        classpath("org.springframework.boot:spring-boot-gradle-plugin:2.3.3.RELEASE")
    }
}

plugins {
    id 'org.springframework.boot' version '2.3.3.RELEASE'
    id 'io.spring.dependency-management' version '1.0.10.RELEASE'
    id 'java'
    id 'idea'
}

group 'com.example'
version = '1.0.0'

sourceCompatibility = 11
targetCompatibility = 11

tasks.withType(JavaCompile) {
    options.encoding = 'UTF-8'
}

def daSdk = '1.11.1'

repositories {
    maven { url "https://repo.maven.apache.org/maven2" }
}

sourceSets.main.resources.includes = [ "**" ]

dependencies {

    implementation 'org.springframework.boot:spring-boot-starter'
    compile('org.springframework.boot:spring-boot-starter-web')
    testImplementation('org.springframework.boot:spring-boot-starter-test') {
        exclude group: 'org.junit.vintage', module: 'junit-vintage-engine'
    }
    compile (group: 'com.daml', name: 'bindings-rxjava', version:"${daSdk}") {
        exclude(module: 'protobuf-lite')
    }
    implementation 'org.projectlombok:lombok'
    annotationProcessor 'org.projectlombok:lombok'
}

task dar(type: Exec) {
    commandLine 'daml', 'build'
}

task codegen(type: Exec) {
    commandLine 'daml', 'codegen', 'java'
}

perbergman:

repositories {
    maven { url "https://repo.maven.apache.org/maven2" }
}

don’t you just need here mavenCentral () ?

Yes, this was my ‘legacy’ build file

so the test-java project specifies a Spark class , and unfortunately I deleted the pom file, doees any one know the appropriate maven central coordinates for this lib ? thanks

I"m having a general issue with building from Gradle.

First of all , I understand that one has to run “daml build” to code generate from the daml artifact, but one would hope that the generated code would put in the classpath so that Gradle could see it i.e. that would probably be the case if there was actually a gradle plugin for daml
Anyhow gradle builds fail since it can’t find the daml artifact

daml.yaml needs to be set correctly, for example:

codegen:
  java:
    package-prefix: com.example.foo
    output-directory: src/main/java
    verbosity: 2

thanks, this is what was included by the template, however running daml build did not generate the folder nor related source files:

codegen:
java:
package-prefix: com.daml.quickstart.model
output-directory: target/generated-sources/iou
decoderClass: com.daml.quickstart.iou.TemplateDecoder

however daml build , will generated the respective quicstart-0.0.1.dar

daml build will not generate the daml artifacts, you’ll need to run daml codegen java to do that.

ah, so I think I am just starting this adventure in the wrong place i.e. I found the interactive tutorials, I’m trying to mimic them, I used the project generation skeleton etc.

I’m confused as to where I would go to learn how to do something from scratch i.e. I do plan on emulating the IOU project i.e. use the IOU project daml assets, be able to create a sandbox and then via JavaFX generate a UI that effectively goes thru the same user - system dialogue as the React app, I do need to translate this to Groovy , running on Gradle as the build system but I know how to do that given that I know the coordinates for the various dependencies, I just need to understand the bits of daml to do this

also the generated sources need to be made accessible i.e. put on the classpath , right ?

This quickstart project confuses me , a closer look at it and it seems that all it is i.e. IOUMain.java , what I would probably be doing from JavaFX UI

therefore I think I need a project that is all about setting up the daml artifact and running codegen and daml build, so that I can then spawn the test sandbox

as far as unit testing again if setting up for example Spock I would need the generated source in the class path

with IDEA I know how to do that

it would be great if there was an external tool not tied to VSCode that could visualize the sandboxed ledger

I just did this to force it under the customary classPath for Java projects

codegen:
java:
package-prefix: com.daml.quickstart.model
output-directory: src/main/java/
decoderClass: com.daml.quickstart.iou.TemplateDecoder

well I am becoming happier now.

by doing the above I can now mix Groovy and generated daml Java source code which led me to find out that the quickstart tutorial is using deprecated code e.g.

DamlLedgerClient.forHostWithLedgerIdDiscovery()

amiracam:

it would be great if there was an external tool not tied to VSCode that could visualize the sandboxed ledger

ok, I just found about Navigator which of course is not tied up to VSCode, so even happier

amiracam:

by doing the above I can now mix Groovy and generated daml Java source code which led me to find out that the quickstart tutorial is using deprecated code e.g.

DamlLedgerClient.forHostWithLedgerIdDiscovery()

Thanks for reporting this! I’ve opened an issue for it.

quickstart-java is using some deprecated methods

opened 11:55AM - 05 Apr 21 UTC

closed 08:38PM - 06 Apr 21 UTC

anthonylusardi-da

I’ve read a few confusing things in this thread, so here are a few clarifications for future readers.

For various historical reasons, in the 0.x.y releases of the DAML SDK (now Daml Connect SDK), Java libraries had corresponding 100.x.y version numbers. Since 1.0.0, version numbers match, and while there has been a couple renamings (as @cocreature mentioned), I don’t thnk we’ve dropped anything (yet).

The daml build command builds Daml-LF bytecode based on Daml source code, and packages it in the form of DAR files. In order to generate type definitions in other languages, one must use the daml codegen command(s).

Our Java bindings (and Java codegen) target the protobuf/gRPC Ledger API, while our TypeScript bindings (@daml/ledger & @daml/type) and codegen target the JSON/HTTP API. We also provide a completely optional React-specific library (@daml/react) that builds on top of our TypeScript bindings.

Navigator is a separate, standalone (dev-time-only) tool not tied to any codegen, bindings or Daml Studio.

great, meaning that from my perspective all I need is the java generated bindings which I can attach to from my Groovy JavaFX code to manipulate and query the ledger and have no need whatsoever for any json/http api, which I was unclear of where the division was.

Sounds good.

Does a runtime daml ledger explorer exist ?

thanks

amiracam:

Does a runtime daml ledger explorer exist ?

Navigator would function as this for getting a view of the active contracts and templates accessible to a specific party. Daml is strongly permissioned so views are always local to a specific party.

There are also other options depending on your needs:

• The active contract service and transaction service (for historical data) which you can get over the gRPC Ledger API
• An early access feature called Extractor that can pull historical/archived contracts and active contracts from any deployment using Daml for Postgres