Es bleibt weiterhin sehr still um die App. Es gibt bei uns gerade immer noch sehr viel nebenher, aber wir arbeiten immer mal wieder ein bisschen an unseren derzeitigen Themen. Nachdem Peter uns in den letzten Wochen ein eigenes ORM-Framework angelegt hat, war es soweit, uns dem eigentlichen Problem zu widmen: den Relationen. Dabei sind wir nochmal ein Stück weiter gekommen, die Lazy-Loading-Thematik von SpringBoot zu verstehen, vor der wir nun auch stehen. Wir wollten unsere DO’s nicht erben lassen, um uns größtmögliche Flexibilität zu bewahren, sondern mit Annotationen arbeiten. Jetzt stehen wir allerdings vor der Frage, wie das DO sich die Relationen, die zunächst lazy geladen werden sollen, nachträglich beschafft und sind letztendlich wieder bei der Überlegung angekommen, doch zu vererben, um das Nachladen zu vereinfachen. Die Vererbung war auch beim Exposed-Framework von JetBrains, neben der Doppelpflege der Attribute, ein Ausschlusskriterium für uns. Nun Fragen wir uns, ob es sich nicht vielleicht doch lohnt, nochmal einen Blick auf Exposed zu werfen und werden dies als nächstes noch einmal angehen.
Nach gefühlt wochenlangem Herumprobieren ist es geschafft. Wir haben eine vollwertige Library auf GithubPackages, in der auch die transitiven Dependencies automatisch beim Einbinden in ein Projekt geladen werden. Transitive Dependencies sind die, die von unserer intern Library genutzt werden und deshalb auch im Projekt, in dem die Library eingebunden wird, vorhanden sein müssen. Bisher mussten wir diese händisch unserem verwendenden Projekt hinzufügen. Der Trick hierbei ist das Hinzufügen der Dependencies in das pom.xml, also das Metafile für die Lib, welches ebenfalls gepublished wird:
build.gradle:
...
publishing {
publications {
bar(MavenPublication) {
groupId getGroupId()
artifactId getArtifactId()
version getVersionName()
artifact("$buildDir/libs/${getArtifactId()}.jar")
//add all implementation dependencies to the pom file
pom.withXml {
def dependenciesNode = asNode().appendNode('dependencies')
configurations.implementation.allDependencies.each {
dep ->
def newDepNode =
dependenciesNode.appendNode('dependency')
newDepNode.appendNode('groupId', dep.group)
newDepNode.appendNode('artifactId', dep.name)
newDepNode.appendNode('version', dep.version)
}
}
}
}
Um den Inhalt des pom-Files zu überprüfen, kann im Gradle-Menü der Punkt „generatePomFileForBarPublication“ unter dem Punkt „Publish“ ausgeführt werden und anschließend das pom-File im Build-Ordner geprüft werden. Hier finden sich dann die Dependencies, welche beim Herunterladen der Lib automatisch mit geladen werden:
pom.xml:
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<modelVersion>4.0.0</modelVersion>
<groupId>com.outlivethesun</groupId>
<artifactId>serviceprovider</artifactId>
<version>1.0.1</version>
<dependencies>
<dependency>
<groupId>org.reflections</groupId>
<artifactId>reflections</artifactId>
<version>0.9.12</version>
</dependency>
<dependency>
<groupId>org.jetbrains.kotlin</groupId>
<artifactId>kotlin-reflect</artifactId>
<version>1.5.31</version>
</dependency>
</dependencies>
</project>
Im nächsten Schritt können wir nun unsere Framework-Komponenten, wie beispielsweise den ServiceProvider, auslagern und unsere lokalen, doppelten Implementierungen in unseren beiden Projekten ersetzen.
