Arndt Schönbergs Weblog

Freitag Dez. 13, 2019

Phabricator - Zugriff auf SVN Repositories über Tortoise SVN (Windows)

Der Zugriff auf SVN Repositories ist in Phabricator nur über SSH möglich. Dafür wird in

Diffusion User Guide: Repository Hosting

beschrieben, wie dies einzurichten ist. Der eigentliche Zugriff auf SVN Repositories erfolgt nach der Einrichtung immer über den erstellten Phabricator SSH User.
svn+ssh://phabssh@192.168.77.92/diffusion/SVNREPO/
Die Authentifizierung innerhalb von Phabricator erfolgt allerdings gegen die User (Bereich Perople in Phabricator), die in Phabricator angelegt sind. Daher muss beim Verbindungsaufbau sowohl der Phabricator SSH User (in der URL) angegeben als auch die Anmeldedaten des eigentlich ändernden Users übergeben werden.

In diesem Beispiel haben wir folgende Voraussetzungen
  • der Zugriff in Phabricator (SSH) wurde mit dem User "phabssh" realisiert
  • auf dem Phabricator Server läuft einn SSH Server für diesen Zugriff auf dem Port 2222
  • es gibt einen Nutzer in Phabricator "developer1" für den ein SSH Public Key hinterlegt wurde
  • Tortoise SVN und Putty sind auf dem Windows Client installiert
  • das Repository hat das Call Sign "SVNREPO"
  • Phabricator läuft auf dem (internen) Server 192.168.77.92
Um die Verbindung zu Phabricator aufzubauen erstellen, wir in Putty eine Verbindung mit dem Namen "phabssh@192.168.77.92" erstellt (Achtung: wenn in dem Namen "_" verwendet wird, scheitert der Zugriff!). TortoiseSVN ersetzt in jeder URL den genannten Server durch eine gleichlautende gespeicherte Putty-Sitzung.

In der Putty Sitzung wird der Server (hier die IP 192.168.77.92) und der Port 2222 angegeben. Des Weiteren hinterlegen wir in der Einstellung (connection, SSH, Auth) den private Schlüssel des eincheckenden Nutzers (das Gegenstück zu dem öffentlichen Schlüssel, den wir in Phabricator hinterlegt haben).

In TortoiseSVN wird mit der URL

svn+ssh://phabssh@192.168.77.92/diffusion/SVNREPO/
auf das SVN-Repository zugegriffen. Der Nutzer in der URL bleibt bei allen Zugriffen "phabssh". Phabricator prüft die hinterlegten öffentlichen Schlüssel der in Phabricator erstellten Nutzer gegen den übermittelten Schlüssel und kann somit bestimmen welcher Nutzer gerade aktiv ist.

Anmerkungen

Ich bin entgegen dem Trend immer noch ein Fan von SVN. Die Anbindung in Phabricator ist nicht so einfach, wie man es sich wünchen würde. Aber Sie funktioniert und einem produktiven Einsatz steht nichts im Wege!!

Fragen und Anmerkungen

Für Fragen und Anmerkungen sendet mir gerne eine eMail. Wegen der DSGVO habe ich derzeit die Kommentarfunktionen abgestellt.

Umstellung JEE 8 auf Jakarta 8

Um auf die zukünftigen freien Weiterentwicklungen vorbereitet zu sein, sollten die Maven Builds entsprechend angepasst werden. Da die Packages weitestgehend gleich geblieben sind, führt dies zu sehr wenig Änderungsaufwand im Quellcode. Es müssen folgende Dependencies ausgetauscht werden:

<dependency>
    <groupId>javax</groupId>
    <artifactId>javaee-api</artifactId>
    <version>8.0</version>
    <scope>provided</scope>
<dependency>
wird zu
<dependency>
    <groupId>jakarta.platform</groupId>
    <artifactId>jakarta.jakartaee-api</artifactId>
    <version>8.0.0</version>
    <scope>provided</scope>
</dependency>

Fragen und Anmerkungen

Für Fragen und Anmerkungen sendet mir gerne eine eMail. Wegen der DSGVO habe ich derzeit die Kommentarfunktionen abgestellt.

Fehler beim Testen: path resource [activiti.cfg.xml] cannot be opened

Umgebung

  • Wildfly
  • Camunda
  • JUnit

Situation

Innerhalb einer JEE Anwendung verwenden wir Camunda. Beim erstellen von Tests werden mit
 
    @Rule
    public ProcessEngineRule processEngineRule = new ProcessEngineRule();
die ProcessEngine und die Dienste zur Verfügung gestellt. Wir starten einen Test mit
 
    @Test
    @Deployment(resources = {MyConstants.PROCESS_NAME)
    public void executeProcessStraighForward() throws Exception {
    ....
und erhalten den Fehler
 
org.springframework.beans.factory.BeanDefinitionStoreException: IOException parsing XML 
document from class path resource [activiti.cfg.xml]; 
nested exception is java.io.FileNotFoundException: class path resource [activiti.cfg.xml] 
cannot be opened because it does not exist
obwohl wir definitiv kein Spring verwenden (und auch nicht verwenden wollen :-) ).

Ursache

Die JUnit Rule findet keine camunda.cfg.xml und nutzt den Fallback activiti.cfg.xml. Dies geschieht aus Kompatibilitätsgründen und wurde beim Fork von Activiti integriert. Es muss also in den Ressourcen der Tests eine camunda.cfg.xml angelegt oder diese programmatisch erstellt werden
 
@Rule
public ProcessEngineRule rule = new ProcessEngineRule(this.createProcessEngineProgramatically());
...
protected ProcessEngine createProcessEngineProgramatically() {
    StandaloneInMemProcessEngineConfiguration processEngineConfiguration = new 
        StandaloneInMemProcessEngineConfiguration();
    processEngineConfiguration.setCustomPostBPMNParseListeners(Arrays.asList(new BpmnParseListener[]{new FoxFailedJobParseListener()}));
    return processEngineConfiguration.buildProcessEngine();
}

Fragen und Anmerkungen

Für Fragen und Anmerkungen sendet mir gerne eine eMail. Wegen der DSGVO habe ich derzeit die Kommentarfunktionen abgestellt.

Calendar

Feeds

Search

Links

Navigation