ok

Author: s2oBCN

build.gradle

@@ -1,5 +1,10 @@
 buildscript {
   ext {
+    groovyallVersion = '3.0.9'
+    springbootVersion = "2.6.2"
+    spockCoreVersion = "2.0-groovy-3.0"
+    spockReportsVersion = '2.1-groovy-3.0'
+
     nexus_url = "${project.findProperty('nexus_url') ?: System.getenv('NEXUS_HOST')}"
     nexus_user = "${project.findProperty('nexus_user') ?: System.getenv('NEXUS_USERNAME')}"
     nexus_pw = "${project.findProperty('nexus_pw') ?: System.getenv('NEXUS_PASSWORD')}"
@@ -51,32 +56,21 @@ buildscript {
   }
 }
 
-buildscript {
-  ext {
-    joobyVersion = "1.6.6"
-  }
-
-  dependencies {
-    classpath "org.jooby:jooby-gradle-plugin:$joobyVersion"
-  }
-}
-
 plugins {
-  id "com.github.johnrengelman.shadow" version "5.1.0"
-  id "com.google.osdetector" version "1.6.2"
-  id "io.spring.dependency-management" version "1.0.8.RELEASE"
+  id "groovy"
+  id 'application'
+  id "com.github.johnrengelman.shadow" version "7.1.1"
+  id "com.google.osdetector" version "1.7.0"
+  id 'com.adarshr.test-logger' version '3.1.0'
+  id 'jacoco'
+  id 'org.springframework.boot' version "${springbootVersion}"
+  id 'com.bmuschko.docker-spring-boot-application' version '7.1.0'
 }
 
-apply plugin: "application"
-apply plugin: "distribution"
-apply plugin: "groovy"
-apply plugin: "jooby"
-apply plugin: "jacoco"
-
 repositories {
+  mavenCentral()
   if (no_nexus) {
     println("using repositories 'jcenter' and 'mavenCentral', because property no_nexus=$no_nexus")
-    jcenter()
     mavenCentral()
   } else {
     println("using nexus repositories")
@@ -107,63 +101,97 @@ repositories {
 }
 
 group = 'org.ods'
-version = '0.1'
-mainClassName = "app.App"
-sourceCompatibility = 1.8
+version = '1.0'
+mainClassName = "org.ods.document.generation.svc.App"
 
-dependencyManagement {
-  imports {
-    mavenBom "org.jooby:jooby-bom:$joobyVersion"
+java {
+  toolchain {
+    languageVersion.set(JavaLanguageVersion.of(11))
   }
 }
 
+compileGroovy {
+  groovyOptions.javaAnnotationProcessing = true
+}
+
 dependencies {
-  compile "com.github.ben-manes.caffeine:caffeine:2.7.0"
-  compile "com.github.jknack:handlebars:4.1.2"
-  compile "commons-io:commons-io:2.6"
-  compile "io.github.openfeign:feign-core:10.2.3"
-  compile "io.github.openfeign:feign-gson:10.2.3"
-  compile "io.github.openfeign:feign-okhttp:10.2.3"
-  compile "net.lingala.zip4j:zip4j:1.3.3"
-  compile "org.apache.httpcomponents:httpclient:4.5.8"
-  compile "org.codehaus.groovy:groovy-all:2.5.7"
-  compile "org.jooby:jooby-jackson"
-  compile "org.jooby:jooby-netty"
-
-  compile "io.netty:netty-transport-native-epoll:${dependencyManagement.importedProperties['netty.version']}:${osdetector.classifier.contains('linux') ? 'linux-x86_64' : ''}"
-  compile "io.netty:netty-tcnative-boringssl-static:${dependencyManagement.importedProperties['boringssl.version']}" 
-
-  testCompile "junit:junit:4.12"
-  testCompile "com.github.stefanbirkner:system-rules:1.19.0" // for managing environment variables
-  testCompile "com.github.tomakehurst:wiremock:2.23.2"       // for mocking HTTP server reponses
-  testCompile "io.rest-assured:rest-assured:4.0.0"           // for validating REST services
-  testCompile "org.spockframework:spock-core:1.3-groovy-2.5"
+  implementation (group: 'org.codehaus.groovy', name: 'groovy-all', version: groovyallVersion){
+    exclude group: "org.codehaus.groovy", module: "groovy-test-junit5"
+  }
 
+  implementation "org.springframework.boot:spring-boot-starter:${springbootVersion}"
+  implementation "org.springframework.boot:spring-boot-starter-web:${springbootVersion}"
+  implementation "org.springframework.boot:spring-boot-starter-cache:${springbootVersion}"
+
+  implementation("javax.inject:javax.inject:1")
+  implementation("javax.cache:cache-api:1.1.1")
+
+  implementation 'com.fasterxml.jackson.core:jackson-databind'
+  implementation 'com.github.ben-manes.caffeine:caffeine:3.0.5'
+  implementation 'com.github.jknack:handlebars:4.3.0'
+  implementation 'commons-io:commons-io:2.11.0'
+  implementation 'io.github.openfeign:feign-core:11.8'
+  implementation 'io.github.openfeign:feign-gson:11.8'
+  implementation 'io.github.openfeign:feign-okhttp:11.8'
+  implementation 'net.lingala.zip4j:zip4j:2.9.1'
+  implementation 'org.apache.httpcomponents:httpclient:4.5.13'
   implementation "org.apache.pdfbox:pdfbox:2.0.24"
-}
 
-test {
-  outputs.dir snippetsDir
+  testImplementation "org.junit.jupiter:junit-jupiter-api"
+  testImplementation "org.junit.jupiter:junit-jupiter-engine"
+  testImplementation("uk.org.webcompere:system-stubs-core:1.2.0")
+  testImplementation "org.testcontainers:spock:1.16.2"
+  testImplementation("org.testcontainers:testcontainers:1.16.2")
+
+  testImplementation("org.spockframework:spock-core:${spockCoreVersion}")
+  testImplementation ("com.athaydes:spock-reports:$spockReportsVersion"){ transitive = false }
+  testImplementation "org.spockframework:spock-spring:${spockCoreVersion}"
+  testImplementation "org.springframework.boot:spring-boot-starter-test:${springbootVersion}"
 
-  // Use overrides in conf/application.test.conf in ConfigFactory.load()
-  // TODO: setting application.env should be enough, but apparently isn't
-  systemProperty "application.env", "test"
-  systemProperty "config.resource", "application.test.conf"
+  testImplementation "com.github.stefanbirkner:system-rules:1.19.0" // for managing environment variables
+  testImplementation 'com.github.tomakehurst:wiremock:2.27.2'       // for mocking HTTP server reponses
+  testImplementation 'io.rest-assured:rest-assured:4.4.0'           // for validating REST services
+}
 
+test {
   testLogging {
     showStandardStreams = true
+    exceptionFormat = 'full'
+  }
+  filter {
+    includeTestsMatching "*Spec"
   }
+  useJUnitPlatform()
 
   finalizedBy jacocoTestReport
 }
 
+task dockerTest(type: Test) {
+  group("verification")
+  filter {
+    includeTestsMatching "*IT"
+  }
+  useJUnitPlatform()
+}
+
 jacocoTestReport {
   reports {
     xml.enabled true
   }
 }
 
-/** We diverge from the default resources structure to adopt the Jooby standard: */
-sourceSets.main.resources {
-  srcDirs = ["conf", "public"]
+import com.bmuschko.gradle.docker.tasks.image.*
+task buildImage(type: DockerBuildImage) {
+ // dependsOn createDockerfile
+  inputDir = file("src/main/resources")
+  images.add('docgen-base:latest')
 }
+
+docker {
+  springBootApplication {
+    baseImage = 'docgen-base:latest'
+    ports = [9090, 8080]
+    images = ['docgen:latest']
+    jvmArgs = ['-Dspring.profiles.active=production', '-Xmx2048m']
+  }
+}

conf/application.conf

@@ -0,0 +1,28 @@
+# Use Markdown Architectural Decision Records
+
+## Context and Problem Statement
+
+We want to record architectural decisions made in this project.
+Which format and structure should these records follow?
+
+## Considered Options
+
+* [MADR](https://adr.github.io/madr/) 2.1.2  The Markdown Architectural Decision Records
+* [Michael Nygard's template](http://thinkrelevance.com/blog/2011/11/15/documenting-architecture-decisions)  The first incarnation of the term "ADR"
+* [Sustainable Architectural Decisions](https://www.infoq.com/articles/sustainable-architectural-design-decisions)  The Y-Statements
+* Other templates listed at <https://github.com/joelparkerhenderson/architecture_decision_record>
+* Formless  No conventions for file format and structure
+
+## Decision Outcome
+
+Chosen option: "MADR 2.1.2", because
+
+* Implicit assumptions should be made explicit.
+  Design documentation is important to enable people understanding the decisions later on.
+  See also [A rational design process: How and why to fake it](https://doi.org/10.1109/TSE.1986.6312940).
+* The MADR format is lean and fits our development style.
+* The MADR structure is comprehensible and facilitates usage & maintenance.
+* The MADR project is vivid.
+* Version 2.1.2 is the latest one available when starting to document ADRs.
+
+<!-- markdownlint-disable-file MD013 -->

conf/application.test.conf

@@ -0,0 +1,35 @@
+# {short title of solved problem and solution}
+
+* Status: accepted
+* Deciders: Sergio Sacristán
+* Date: 2021-12-22
+
+## Context and Problem Statement
+
+In order to evolve DocGen service to migrate here the LevaDoc feature, initially implemented
+in the SharedLib, we need to improve LevaDoc architecture to make it more maintainable.
+
+## Decision Drivers
+
+* Maintainability: speed up the development with better modularization of the code
+* Testability.
+* Extensibility.
+* Performance: this is not a big problem. As the API will be executed from a batch, we don't care if the response takes 2 seconds more or less
+
+## Considered Options
+
+* jooby with Dagger and Groovy: poor documentation and examples
+* jooby with SpringFramework and Groovy: poor documentation and examples
+* SpringFramework and Groovy
+
+## Decision Outcome
+
+Chosen option: "SpringFramework", because:
+- There's a lot of documentation and examples. Easy to solve problems
+- There's a bigger community of users: easy to involve new developers
+- Better integration with more frameworks, means also better extensibility
+
+### Negative Consequences 
+
+* We should do a big refactor
+

conf/logback.xml

@@ -0,0 +1,80 @@
+# {short title of solved problem and solution}
+
+* Status: {proposed | rejected | accepted | deprecated | … | superseded by [ADR-0005](0005-example.md)} <!-- optional -->
+* Deciders: {list everyone involved in the decision} <!-- optional -->
+* Date: {YYYY-MM-DD when the decision was last updated} <!-- optional -->
+
+Technical Story: {description | ticket/issue URL} <!-- optional -->
+
+## Context and Problem Statement
+
+{Describe the context and problem statement, e.g., in free form using two to three sentences. You may want to articulate the problem in form of a question.}
+
+## Decision Drivers <!-- optional -->
+
+* {driver 1, e.g., a force, facing concern, …}
+* {driver 2, e.g., a force, facing concern, …}
+* … <!-- numbers of drivers can vary -->
+
+## Considered Options
+
+* {option 1}
+* {option 2}
+* {option 3}
+* … <!-- numbers of options can vary -->
+
+## Decision Outcome
+
+Chosen option: "{option 1}", because {justification. e.g., only option, which meets k.o. criterion decision driver | which resolves force {force} | … | comes out best (see below)}.
+
+### Positive Consequences <!-- optional -->
+
+* {e.g., improvement of quality attribute satisfaction, follow-up decisions required, …}
+* …
+
+### Negative Consequences <!-- optional -->
+
+* {e.g., compromising quality attribute, follow-up decisions required, …}
+* …
+
+## Pros and Cons of the Options <!-- optional -->
+
+### {option 1}
+
+{example | description | pointer to more information | …} <!-- optional -->
+
+* Good, because {argument a}
+* Good, because {argument b}
+* Bad, because {argument c}
+* … <!-- numbers of pros and cons can vary -->
+
+### {option 2}
+
+{example | description | pointer to more information | …} <!-- optional -->
+
+* Good, because {argument a}
+* Good, because {argument b}
+* Bad, because {argument c}
+* … <!-- numbers of pros and cons can vary -->
+
+### {option 3}
+
+{example | description | pointer to more information | …} <!-- optional -->
+
+* Good, because {argument a}
+* Good, because {argument b}
+* Bad, because {argument c}
+* … <!-- numbers of pros and cons can vary -->
+
+## Links <!-- optional -->
+
+* {Link type} {Link to ADR} <!-- example: Refined by [ADR-0005](0005-example.md) -->
+* … <!-- numbers of links can vary -->
+
+<!-- markdownlint-disable-file MD013 -->
+https://examples.javacodegeeks.com/spring-boot-mockmvc-tutorial/
+
+When unit testing a service, the standard unit is usually the service class, simple as that. The test will mock out the layer underneath  in this case the DAO/DAL layer and verify the interactions on it. Exact same thing for the DAO layer  mocking out the interactions with the database (HibernateTemplate in this example) and verifying the interactions with that.
+
+This is a valid approach, but it leads to brittle tests  adding or removing a layer almost always means rewriting the tests entirely. This happens because the tests rely on the exact structure of the layers, and a change to that means a change to the tests.
+To avoid this kind of inflexibility, we can grow the scope of the unit test by changing the definition of the unit  we can look at a persistent operation as a unit, from the Service Layer through the DAO and all the way day to the raw persistence  whatever that is. Now, the unit test will consume the API of the Service Layer and will have the raw persistence mocked out  in this case, the HibernateTemplate: