Commit e24b0530 authored by Christian Kniss's avatar Christian Kniss

NERZ: Umstellung auf Gradle (lfd.)

parent 120ff147
de.inovat.kex-ftp-build:
image:
openjdk:8-jdk-alpine
script:
- ./gradlew build
V 2.0.1
=======
- Debug-Ausgabe korrigiert.
Versionsverlauf
===============
## [Noch nicht veröffentlicht]
## [Version 2.0.2]
- NERZ: Umstellung auf Gradle, Build durch FTB und Bereitstellung auf NERZ-Repositories
## Version 2.0.1
- Übernahme vor Umstellung auf Gradle
- Debug-Ausgabe korrigiert.
## Version 2.0.0
V 2.0.0
=======
- Zusätzliche Übertragungsprotokoll für SFTP integriert
- Neue Aufrufparamter
- -istFtp=ja|nein / Default-Wert = ja
- -ftpServerPort=ZAHL / Default-Wert bei -istFtp=ja ist 21, bei -istFtp=nein ist 22
- `-istFtp=ja|nein` / Default-Wert = ja
- `-ftpServerPort=ZAHL` / Default-Wert bei `-istFtp=ja` ist 21, bei `-istFtp=nein` ist 22
[Noch nicht veröffentlicht]: https://gitlab.nerz-ev.de/ERZ/SWE_de.inovat.kex.ftp/compare/v2.0.2...HEAD
[Version 2.0.2]: https://gitlab.nerz-ev.de/ERZ/SWE_de.inovat.kex.ftp/compare/v2.0.1...v2.0.2
Hinweise zur Bearbeitung / Beteiligung
======================================
Für Änderungen an dem Projekt ist zuerst ein Eintrag (Issue) mit dem Tag "Feature-Wunsch" oder "Bug"
anzulegen, damit die übernommen Änderungen auch einem Problem und einer potentiell erfolgten Diskussion
zugeordnet werden können. Solange das Fehler- und Änderungsmanagement noch über die bisherigen NERZ-Bugtracker
abgewickelt wird, ist zudem eine Referenz auf den dortigen Eintrag vorzunehmen.
Vor der Bearbeitung sollte man den entsprechenden Eintrag persönlich übernehmen
und einen Bugfix- oder Feature-Branch anlegen.
Feature-Branches werden benannt als "feature/{name}", Bugfix-Branches als "hotfix/{name}".
Der Name sollte beschreiben, was innerhalb des Branches geändert wird und **nicht den Name des Bearbeiters**.
Feature-Wünsche werden auf Basis des "develop"-Branches umgesetzt und führen letztendlich zu einem Release einer
neuen Version auf dem zweiten Level, d.h. 0.1.0 wird mindestens 0.2.0 oder in der Hauptversion, d. h. aus z. B. 1.x.y wird 2.0.0, wenn **keine** Abwärtskompatibilität besteht.
Bugfixes sollten auf dem "master"-Branch beruhen und führen zu einer neuen Version auf dem dritten Level, d.h. aus 0.1.0 wird 0.1.1.
Die Änderungen werden dann natürlich auch in den "develop"-Branch gemerged. Damit können Bugfixes kurzfristig erfolgen
ohne den Zwang gleich alle Änderungen, die sich schon im Develop-Zweig befinden mit zu veröffentlichen.
Werden im Rahmen eines Auftrags mehrere Feature-Wünsche oder Bugfixes bearbeitet, kann auch einheitlich vom "develop"-Branch gemerged werden (konkrete Abstimmung im Zweifelsfall mit der NERZ-FTB).
Branches sollten nur für einen **einzelnen Eintrag** angelegt werden.
Die Branches können nach dem Merge in den Ursprungs-Branch entfernt werden (Das Löschen erfolgt automatisch,
wenn der entsprechende Haken beim Anlegen des Merge-Request gesetzt wird).
Ein Merge-Request sollte folgende Punkte berücksichtigen:
- die Änderungen, die mit dem Request verbunden sind sollten in kurzer prägnanter Form in das CHANGELOG-File eingetragen werden. Der Eintrag erfolgt dabei im Abschnitt "Noch nicht veröffentlicht". Die Versionsnummer wird dort erst beim Release ergänzt (also letztlich bei der Übernahme durch die NERZ-FTB).
- wenn es notwendig ist, neue Features oder Änderungen zu beschreiben muss das README-File angepasst werden
- Änderungen am Code sollten keinen auskommentierten alten Code enthalten, für den Zugriff auf die Historie ist ja GIT vorgesehen
- die bearbeiteten Einträge sollten im Kommentar für den jeweiligen Commit oder für den Merge-Request mit "Fixes #{Eintragsnummer}" um die Zuordnung zu erhalten und das automatische Schließen zu ermöglichen
**Abgelehnte Merge-Request brauchen nicht gelöscht werden!**
Angemerkte und diskutierte Probleme, die eine Übernahme verhindern, sollten stattdessen bearbeitet werden bis der Merge-Request übernommen werden kann. **Ein neuer Request ist nicht erforderlich!**
\ No newline at end of file
This diff is collapsed.
# FTP-Verzeichnisüberwachung
## Übersicht
Die SWE FTP-Verzeichnisüberwachung überwacht zyklisch Ordnerinhalte auf einem externen FTP-Server
auf den Eingang von neuen, durch die SWE BASt-Band weiterzuverarbeitenden (importierenden)
Dateien im BASt-Format (V2004 oder V2007). Sobald die SWE FTP-Verzeichnisüberwachung neue
Dateien im zu überwachenden Verzeichnis erkennt, meldet sie dies der SWE BASt-Band über den
Datenverteiler. Nach erfolgreicher Verarbeitung der Daten durch die SWE BASt-Band verschiebt
die SWE FTP-Verzeichnisüberwachung die Daten in ein weiteres Verzeichnis mit bearbeiteten Dateien
(Miniarchiv zur Nachverfolgbarkeit der Aktivitäten).
Bei den Importdateien handelt es sich um BAST-Daten im Format V2004 bzw. V2007 gemäß
Definition der BASt.
(für die SWE FTP-Verzeichnisüberwachung ist das Format nicht relevant, für die SWE BASt-Band,
welche letztlich die Daten verarbeitet, ist dies aber zwingend notwendig.)
Diese Dateien werden i.d.R. durch externe Ingenieurbüros
geliefert (aus den Zähldaten der Langzeitzählstellen).
Die zu überwachenden Verzeichnisse können über Aufrufparameter festgelegt werden.
Weiterhin unterstützt werden die Überwachung von FTP- und SFTP-Servern sowie der
Passivmodus bei der FTP-Übertragung und natürlich die Übertragung mit Authentifizierung.
Die nachfolgende Abbildung zeigt vereinfacht die Funktionsweise der SWE FTP-Verzeichnisüberwachung.
## Disclaimer
Copyright (C) 2018 inovat - Dipl.-Ing. H. C. Kniß
This program is free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation, either version 3 of the License, or
(at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program. If not, see <http://www.gnu.org/licenses/>.
Dieses Programm ist Freie Software: Sie können es unter den Bedingungen
der GNU General Public License, wie von der Free Software Foundation,
Version 3 der Lizenz oder (nach Ihrer Wahl) jeder neueren
veröffentlichten Version, weiterverbreiten und/oder modifizieren.
Dieses Programm wird in der Hoffnung, dass es nützlich sein wird, aber
OHNE JEDE GEWÄHRLEISTUNG, bereitgestellt; sogar ohne die implizite
Gewährleistung der MARKTFÄHIGKEIT oder EIGNUNG FÜR EINEN BESTIMMTEN ZWECK.
Siehe die GNU General Public License für weitere Details.
Sie sollten eine Kopie der GNU General Public License zusammen mit diesem
Programm erhalten haben. Wenn nicht, siehe <http://www.gnu.org/licenses/>.
## Kontakt
inovat, Dipl.-Ing. H. C. Kniß
An der Krautwiese 37
D-53783 Eitorf
+49 (0)2243 8464 193
info@inovat.de
www.inovat.de
......@@ -2,7 +2,7 @@
// NERZ-SWE-Plugin
//--------------------------------------------------------------------
plugins {
id "de.bsvrz.gradle.nerzswe" version "0.7.0"
id "de.bsvrz.gradle.nerzswe" version "0.7.2"
}
//--------------------------------------------------------------------
......@@ -14,9 +14,9 @@ version '2.0.2-SNAPSHOT'
// Properties des NERZ-SWE-Plugins:
nerzswe {
mainClassName = 'de.inovat.kex.ftp.Verzeichnisueberwachung'
sweStatus = 'BETA'
sweDatum = ''
mainClassName = 'de.inovat.kex.ftp.Verzeichnisueberwachung'
sweStatus = 'BETA'
sweDatum = ''
}
//--------------------------------------------------------------------
......@@ -24,16 +24,14 @@ nerzswe {
//--------------------------------------------------------------------
String kernsoftware_version = '3.9.7'
dependencies {
//------
// Source:
compile group: 'de.bsvrz.dav', name: 'de.bsvrz.dav.daf', version: kernsoftware_version
compile group: 'de.bsvrz.sys', name: 'de.bsvrz.sys.funclib.debug', version: kernsoftware_version
compile group: 'de.bsvrz.sys', name: 'de.bsvrz.sys.funclib.commandLineArgs', version: kernsoftware_version
compile group: 'de.bsvrz.sys', name: 'de.bsvrz.sys.funclib.application', version: kernsoftware_version
compile group: 'de.bsvrz.sys', name: 'de.bsvrz.sys.funclib.hexdump', version: kernsoftware_version
compile group: 'de.bsvrz.sys', name: 'de.bsvrz.sys.funclib.dataIdentificationSettings', version: kernsoftware_version
compile group: 'de.bsvrz.sys', name: 'de.bsvrz.sys.funclib.asyncReceiver', version: kernsoftware_version
//
compile group: 'com.jcraft', name: 'jsch', version: '0.1.50'
compile group: 'commons-net', name: 'commons-net', version: '3.1'
compile group: 'de.bsvrz.dav', name: 'de.bsvrz.dav.daf', version: kernsoftware_version
compile group: 'de.bsvrz.sys', name: 'de.bsvrz.sys.funclib.debug', version: kernsoftware_version
compile group: 'de.bsvrz.sys', name: 'de.bsvrz.sys.funclib.commandLineArgs', version: kernsoftware_version
compile group: 'de.bsvrz.sys', name: 'de.bsvrz.sys.funclib.application', version: kernsoftware_version
compile group: 'de.bsvrz.sys', name: 'de.bsvrz.sys.funclib.hexdump', version: kernsoftware_version
compile group: 'de.bsvrz.sys', name: 'de.bsvrz.sys.funclib.dataIdentificationSettings', version: kernsoftware_version
compile group: 'de.bsvrz.sys', name: 'de.bsvrz.sys.funclib.asyncReceiver', version: kernsoftware_version
compile group: 'com.jcraft', name: 'jsch', version: '0.1.50'
compile group: 'commons-net', name: 'commons-net', version: '3.1'
}
......@@ -2,4 +2,4 @@ distributionBase=GRADLE_USER_HOME
distributionPath=wrapper/dists
zipStoreBase=GRADLE_USER_HOME
zipStorePath=wrapper/dists
distributionUrl=https\://services.gradle.org/distributions/gradle-4.4.1-bin.zip
distributionUrl=https\://services.gradle.org/distributions/gradle-4.5-bin.zip
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment