rades.tag-generator

Automatische Generierung von Schlagworten aus einem Text.

License	GNU GENERAL PUBLIC LICENSE Version 3, 29 June 2007
GroupId	com.github.funthomas424242
ArtifactId	rades.tag-generator
Last Version	1.0.0
Release Date	Jun 4, 2018
Type	jar
Description	rades.tag-generator Automatische Generierung von Schlagworten aus einem Text.
Project URL	https://github.com/FunThomas424242/rades.tag-generator
Project Organization	PIUG
Source Code Management	https://github.com/FunThomas424242/rades.tag-generator

Download rades.tag-generator

Filename	Size
rades.tag-generator-1.0.0.pom
rades.tag-generator-1.0.0.jar	26 KB
rades.tag-generator-1.0.0-sources.jar	23 KB
rades.tag-generator-1.0.0-javadoc.jar	47 KB
rades.tag-generator-1.0.0-jar-with-dependencies.jar	22 MB

How to add to project

Apache Maven

<!-- https://jarcasting.com/artifacts/com.github.funthomas424242/rades.tag-generator/ -->
<dependency>
    <groupId>com.github.funthomas424242</groupId>
    <artifactId>rades.tag-generator</artifactId>
    <version>1.0.0</version>
</dependency>

Gradle Groovy

// https://jarcasting.com/artifacts/com.github.funthomas424242/rades.tag-generator/
implementation 'com.github.funthomas424242:rades.tag-generator:1.0.0'

Gradle Kotlin

// https://jarcasting.com/artifacts/com.github.funthomas424242/rades.tag-generator/
implementation ("com.github.funthomas424242:rades.tag-generator:1.0.0")

Apache Buildr

'com.github.funthomas424242:rades.tag-generator:jar:1.0.0'

Apache Ivy

<dependency org="com.github.funthomas424242" name="rades.tag-generator" rev="1.0.0">
  <artifact name="rades.tag-generator" type="jar" />
</dependency>

Groovy Grape

@Grapes(
@Grab(group='com.github.funthomas424242', module='rades.tag-generator', version='1.0.0')
)

Scala SBT

libraryDependencies += "com.github.funthomas424242" % "rades.tag-generator" % "1.0.0"

Leiningen

[com.github.funthomas424242/rades.tag-generator "1.0.0"]

Dependencies

compile (5)

Group / Artifact	Type	Version
edu.stanford.nlp : stanford-corenlp	jar	3.9.1
com.github.funthomas424242 : rades-annotations	jar	3.1.1
org.slf4j : slf4j-api	jar	1.7.25
javax.validation : validation-api	jar	2.0.1.Final
com.google.guava : guava	jar	25.1-jre

test (5)

Group / Artifact	Type	Version
org.junit.jupiter : junit-jupiter-api	jar	5.2.0
org.apache.bval : bval-jsr	jar	1.1.2
ch.qos.logback : logback-core	jar	1.2.3
ch.qos.logback : logback-classic	jar	1.2.3
com.kennycason : kumo-core	jar	1.13

Project Modules

There are no modules declared in this project.

RADES

Hier gehts zur Projektdokumentation

Projektziel

Das Ziel des Projektes besteht darin, dem Entwickler Werkzeuge zur Entlastung von stupider, eintöniger Arbeit und stets wiederkehrenden Tätigkeiten an die Hand zu geben. Unter eintönigen Tätigkeiten werden solche verstanden, bei denen der Entwickler im Grundsatz ähnlichen Kode schreibt nur mit geänderten Bezeichnern. So wird die Erweiterung einer Webanwendung um ein Texteingabefeld meist nahezu identisch ablaufen. Irgendwo muss die Persistenzschicht um das Feld erweitet werden, der Backendservice muss das Feld entgegennehmen und es zur Persistenz weitergeben, nebenbei muss der Service den Wert des Feldes auf gültige Werte prüfen. Bei Problemen müssen entsprechende Fehlermeldungen erzeugt werden und in der GUI ist das Feld ebenfalls zu verorten. Hier muss es evtl. noch in den internen State der Anwendung aufgenommen werden und ja auch hier müssen Validierungen realisiert werden und in der Regel die gleichen wie im Service.

Bislang war die Lösung ein Modell in einer DSL zu beschreiben und daraus die entsprechenden Kodeteile zu genieren. Dieses Vorgehen zeigte jedoch nach kurzer Hype- und Erfahrungsphase einige Nachteile auf:

• Es entstehen Aufwände bei der Erstellung und Pflege der DSL (mit der Zeit werden neue Sprachkonstrukte benötigt).

• Generate und manuell programmierte Kodeteile müssen getrennt verwaltet werden, damit die Generierung keine manuelle Arbeit zerstört. Bis dato gab es zwei grundlegende Methoden zur Lösung: a) Einführung geschützter Kodebereiche für manuelle Implementierung. b) Generierung abstrakter Klassen von denen die manuelle konkrete Implementierung abgeleitet wird.

• Die Benutzung von Einmalgeneraten (Falls das Target nicht existiert wird es generiert anderenfalls wird der vorhandene Kode nicht vom Generator angetastet) führt zu Problemen bei fachlichen und technischen Refactoring.

• Eine fachliche Umbenennung führt zu sehr vielen Änderungen (Umbenennungen) im technischen Kode. Da dort aber sowohl die alten Generate wie auch die nun neuen Generate existieren und zusätzlich evtl. Schnittstellen verändert wurden, kann sich der Entwickler vor Compilerfehlern kaum retten. Daher versucht dieser zunächst die alten Generate zu eliminieren, dann die Neuen anzupassen und dann die Fachlichkeit aus den alten von den alten Generaten abgeleiteten Klassen in die neuen Generate zu kopieren. Da die alten Generate lokal nicht mehr vorliegen, hat er sich diese entweder als Backup gesichert oder hat diese mit eingescheckt und greift nun auf die alten Versionen im SCM zurück.

• Auf Grund von Änderungen der DSL oder Unzulänglichkeiten im Buildprozess oder ganz profan aus Performancegründen oder für Refactorings werden die Generate mit ins SCM aufgenommen.

Basierend auf diesen, über Jahrzehnte gesammelten Erfahrungen mit Generator getriebener Entwicklung aus fachlichen Modellen heraus, soll ein neuer Lösungsraum erarbeitet werden. Folgende Lösungsansätze scheinen zielführend zu sein:

Nutzung von Annotationsprozessoren

Mittels Annotationsprozessoren lassen sich neue Kodeteile generieren. Diese lassen sich Typsicher gestalten und unterstützen inkrementelle Kompilation, da der Compiler die Annotationen in einem separaten Schritt und in einer eigenen JVM auswertet. Nachteile:

• Separater Buildschritt

• Schwierige Testbarkeit

• Bestehende Klassen können nicht verändert werden

Nutzung des Plugin Mechanismus des javac Compilers

• Aktuell liegen hierzu keine Erfahrungen vor, allerdings existiert ein vielversprechendes Projekt unter http://manifold.systems/

Versions

Version
1.0.0 Jun 4, 2018