[JAVA] Die Geschichte der Einführung von Gradle als Nachrüstung eines bestehenden Systems, das keine Pakete verwaltet

Über dieses Material

<! - TODO: Seien Sie vorsichtig, wenn die verschiedenen Links und Notationen für 2018 sind. Achten Sie besonders auf den Twitter-Link! !! -> Das Präsentationsmaterial für die Titelsitzung von JJUG CCC 2019 Spring wurde auf Qiita (Twitter: # ccc_a2 veröffentlicht. //twitter.com/search? q =% 23ccc_a2)).

<! - Ersetzen Sie durch das Lautsprecherbild von Speakers deck-> <! - TODO: Linkziel muss korrigiert werden! !! ->

Der Inhalt ist fast der gleiche wie auf der obigen Folie. Bitte sehen Sie ihn leicht lesbar.

Einführung

Maven, Gradle usw., die heute alltäglich sind ...

<! - TODO: Behalte den Rücken der Zeitreihe->

• 2004 : Maven 1.0
• 2005 : Maven 2.0 --2006: Ivy 1.4.1 betritt Apache Incubator
• * Paketverwaltungstool, das von Ivy = Scala (sbt) usw. verwendet wird. </ Small> --2007: Gradle Erstveröffentlichung
• 2010 : Maven 3.0

Unsere Firma M3 Co., Ltd. wurde im Jahr 2000 gegründet (J2SE, die Ära um Java 2). Ich benutze Java seit den Tagen, als Maven, Gradle und Ivy noch nicht da waren.

Das Ergebnis der vollständigen Nutzung von Java in Abwesenheit von Maven und Gradle ...

Wenn Sie "Git Clone" ausführen, lautet die folgende Datei ...

lib/app/hibernate-validator-4.3.0.Final.jar
lib/app/aws-java-sdk-core-1.10.27.jar
lib/app/aws-java-sdk-s3-1.10.27.jar
lib/app/generator-runtime-0.3.0-20050901.1909.jar
lib/app/xalan.jar
lib/app/crimson.jar
                 ...Geht endlos weiter...

Infolge der zunehmenden Anzahl von Bibliotheken, die im Laufe der Geschichte verwendet wurden, rollten 182 ".jar".

Operationen, die .jar direkt verwalten

Ich war mit einem solchen Prozess in einem Wartungszustand:

Der Schmerz, die Bibliothek zu aktualisieren

Beispiel: Ich möchte die Version von aws-java-sdk aktualisieren, um die neuen Funktionen nutzen zu können

Das aws-java-sdk-System hängt indirekt von mehreren Bibliotheken ab

Ich weiß nicht, wie ich 182 .jars aktualisieren soll

Geben Sie die Verwendung neuer AWS-Funktionen auf: cry:

Indirekte Abhängigkeit

Ich benutze kein Glas, also möchte ich es löschen

Vielleicht hängt eines der Gläser davon ab ...

Unnötiges Glas kann nicht gereinigt werden

Um JVM-Versions-Upgrades und Gegenmaßnahmen gegen Sicherheitslücken zu verhindern: cry:

Ich kann keine verschiedenen Werkzeuge verwenden

Ich möchte Informationen zu Sicherheitslücken überprüfen

Überprüfen Sie 182 .jars regelmäßig auf Informationen zu Sicherheitslücken

Robust und begrenzt

Ich neige dazu, es in Ruhe zu lassen

Gradle, Maven usw. können mit dem OWASP-Plugin "Dependency-Check" automatisiert werden ...

Der Hintergrund, der so geworden war

Abgesehen von diesem System wurden Maven und Gradle bereits installiert, aber ...

• Das System gibt es seit seiner Einführung und es hat eine besonders lange Geschichte.
• Das Build-Skript von Ant ist eng zusammengesetzt, und das Ersetzen von Stapeln ist schwierig ――Da die übliche Entwicklungsarbeit ohne Probleme verläuft ... (* Solange die Dunkelheit um die Bibliothek ignoriert wird) </ small>

Unter diesen Umständen kann es weltweit Fälle geben, in denen Paketverwaltungstools nicht enthalten sind.

Fügen Sie Paketverwaltungstools (Gradle, Maven usw.) hinzu!

Aber wie implementiert man es in ein bestehendes Projekt ...?

――Was tun mit den Punkten, die die Arbeitsbelastung erhöhen? ――Was sind die Nebenwirkungen und Auswirkungen des Hinzufügens?

→ Fahren Sie mit dem nächsten Kapitel fort

<! - =================================== # Abschnitt: Strategischer Teil (Gradle) == ================================= ->

Implementierungsstrategie für das Paketverwaltungstool

~ Historische Systemverbesserung __Mögliche __Bereichsdefinition ~

Herausforderungen bei der Implementierung von Paketverwaltungstools

Die Nachrüstung bestehender Systeme birgt eine Reihe von Herausforderungen:

――Ist es gut, dass sich das Glas vor und nach der Einführung des Tools ändert? --Was tun mit schwer zu beschaffenden Gläsern oder Gläsern, die nicht zur Mitte passen?

• Möchten Sie den Erstellungsprozess ändern?

Es ist besser, eine Richtlinie zu haben, damit Sie nicht von Problemen beeinflusst werden.

In unserem Fall festgelegte Richtlinien

• Machen Sie vor und nach der Einführung des Paketverwaltungstools keinen Unterschied in der .jar-Datei.
• Um Bedenken hinsichtlich der Auswirkungen auf die App und der Testlast zu verringern
• Stellen Sie sicher, dass der einzige unvermeidbare Unterschied ein harmloser Unterschied ist (Methode wird später beschrieben) </ small> --Inventar und Ver up sind der Umfang der nächsten Verbesserung
• Berühren Sie den Erstellungsprozess nicht
• Verbessern Sie zunächst das Paketmanagement!

Konzentriert sich darauf, von Paketverwaltungstools zu profitieren Es wurde eine Situation geschaffen, in der Sie sich kleinen und bedeutungsvollen Herausforderungen stellen können.

Geben Sie vor der Einführung des Paketverwaltungstools an

Dies geschah mit der Einführung des Paketverwaltungstools

Vor- und Nachteile der Erhöhung von .jar auf Git

: + 1: Vorteile:

• Einfache Migration von Ant usw.
• Verwenden Sie immer die gleiche JAR-Datei

: -1: Nachteile:

--Ant bleibt

• Wenn Sie wirklich ein Problem mit Ant haben, ersetzen Sie es zu diesem Zeitpunkt
• Wiederholte Aktualisierungen von ".jar" führen dazu, dass das Repository wächst
• Manchmal wird es als Git-Submodul getrennt

Legacy-Verbesserungsstrategie

Identifizieren Sie die wahren "Probleme" und "Verdienste um Änderungen"

Betrachten Sie den "notwendigen und ausreichenden Mindestumfang" dafür.

Erreichen Sie das Ziel mit "kleiner Herausforderung" (hohe Kostenleistung, geringer Schaden, selbst wenn Sie versagen) </ klein>

Anstelle von "Weil es ein Vermächtnis ist, musst du alles töten !!!" Verbesserungen beim Befolgen der vorhandenen guten Punkte und Punkte, die nicht geändert werden müssen.

Technik (Taktik) Teil

Bereitstellungstechnik für das Paketverwaltungstool: Nachrüsten von Gradle

~ Spezifische Maßnahmen zur Bewältigung verschiedener Probleme, die tendenziell nachgerüstet werden ~

Gradle or Maven

Gradle wird für Anwendungen wie diese empfohlen:

• Flexibilität: Die flexible Verarbeitung kann mit Groovy und Kotlin DSL beschrieben werden --Maven ist möglicherweise nicht in der Lage, die Struktur historischer Projekte zu handhaben
• Untersuchung: Groovy Javadoc ist leichter zu lesen (subjektiv) </ klein>
• Produktivität: Nutzen Sie den Debugger der IDE voll aus
• Du musst nicht wie eine Black Box kämpfen
• Reproduzierbarkeit: Mit Gradle Wrapper ist es (relativ) einfach, die Reproduzierbarkeit des Verhaltens sicherzustellen

* Im Allgemeinen ist Maven besser als andere. </ Small>

Dateikopie von Gradle

Einführung von Gradle unter Verwendung des vorhandenen Build-Systems Ich möchte die folgenden Dateien mit Gradle in das angegebene Verzeichnis kopieren:

--Jar, das von der Kompilierungszeit und der Laufzeit abhängt

• Glas, das vom Unit-Test abhängt
• Source jar

Ich möchte auch automatisch die .classpath-Datei (später beschrieben) </ small> pflegen.

def compileJarCopyTo = 'development/lib/app'

task downloadJars() {
  doLast {
    //Am Kopierziel*.Löschen Sie das Glas
    delete fileTree(dir: compileJarCopyTo, include: '*.jar')

    //eine Kopie machen
    copy {
      from configurations.compile
      into compileJarCopyTo
    }
  }
}

copy {
  // testCompile =Kopieren Sie die abhängigen Gläser mit Test
  from configurations.testCompile

  into testCompileJarCopyTo

  //Ignorieren Sie Gläser, die dem angegebenen Muster entsprechen
  exclude 'jmockit-*.jar'
}

import org.gradle.jvm.JvmLibrary
import org.gradle.language.base.artifact.SourcesArtifact
import org.gradle.api.artifacts.query.ArtifactResolutionQuery
import org.gradle.internal.component.external.model.DefaultModuleComponentIdentifier

eclipse.classpath.file {
    whenMerged { classpath ->
        classpath.entries.findAll { entry -> entry.kind == 'lib' }.each {
            it.path = it.path.replaceFirst("${projectDir.absolutePath}/", '')
            it.exported = false
        }
    }
}

8c8
< Implementation-Version: 2.4.0 701827 - 2008-10-05 16:46:27
> Implementation-Version: 2.4.0 701827 - 2008-10-05 16:44:47

2c2
< final class com.google.inject.servlet.ServletScopes$1 implements com.google.inject.Scope {
> class com.google.inject.servlet.ServletScopes$1 implements com.google.inject.Scope {

repositories {
  maven {
    url 'http://central.maven.org/maven2/'    
  } // mavenCentral()Ich wage es nicht, die Kurznotation zu verwenden(Siehe unten)

  maven {
    url "http://URL des privaten Repositorys"
  }
}

<project>
  <modelVersion>4.0.0</modelVersion>

  <!--Identifikationsinformationen dieses Glases selbst-->
  <groupId>com.m3</groupId> <artifactId>m3generator</artifactId>
  <version>1.0.0</version>

  <!--Informationen zu dem Glas, von dem dieses Glas abhängt-->
  <dependencies>
    <dependency>
        <groupId>log4j</groupId>
        <artifactId>log4j</artifactId>
        <version>1.2.17</version>
    </dependency>
    ...

repositories {
  maven { // Maven central
    url 'http://central.maven.org/maven2/'    

    content {
      excludeGroup 'com.sun.jmx' //Bekomme diese Gruppe nicht von hier
      excludeModule 'jdom', 'jdom' //Erhalten Sie diese Bibliothek nicht von hier
    }
    //MavenCentral, um die obige Beschreibung vorzunehmen()Ich verwende nicht die abgekürzte Notation wie
  }