Autor: Matthias Staud

Veröffentlicht am

Maven Dependencies und Plugins aktuell halten – der pragmatische Guide

 

Regelmäßige Dependency-Pflege ist keine Kür, sondern ein fester Teil stabiler Softwareentwicklung.

Warum das überhaupt wichtig ist

Veraltete Dependencies sind nicht nur unschön, sondern konkret riskant:

  • Sicherheitslücken in Bibliotheken wie Jackson oder Log4j
  • Inkompatibilitäten mit neueren JDK-Versionen
  • Build-Probleme durch veraltete Maven-Plugins
  • technische Schulden, die spätere Upgrades unnötig teuer machen

Regelmäßige Updates sorgen deshalb nicht nur für Sicherheit, sondern auch für planbare Wartung.

Kurzfassung für Eilige

Wenn Du nur einen alltagstauglichen Standardprozess willst, reicht oft schon das hier:

mvn versions:display-property-updates
mvn versions:display-plugin-updates
mvn versions:display-dependency-updates
mvn versions:update-properties -DallowMajorUpdates=false
mvn clean test

Das wichtigste Tool: versions-maven-plugin

Das zentrale Werkzeug für diesen Workflow ist das Versions Plugin:

mvn versions:display-dependency-updates

Du musst es in der Regel nicht separat installieren – Maven lädt es automatisch nach.

  • zeigt verfügbare Updates an
  • hebt Versionen automatisch an
  • aktualisiert Properties
  • beschränkt Updates auf Minor oder Patch

1. Veraltete Versionen erkennen

Dependencies prüfen

mvn versions:display-dependency-updates

Beispielausgabe:

commons-lang3 ............ 3.12.0 -> 3.20.0
jackson-databind ........ 2.13.4 -> 2.20.0

Plugins prüfen

mvn versions:display-plugin-updates

Gerade alte Plugins sind oft eine unterschätzte Ursache für Build-Probleme.

Properties prüfen

Wenn Du Versionen zentral über Properties pflegst, bekommst Du die sauberste Update-Strategie:

<junit.version>3.11.0</junit.version>

Dazu passt dieser Befehl:

mvn versions:display-property-updates

Effektives POM verstehen

mvn help:effective-pom

Damit erkennst Du geerbte Versionen, Parent-POM-Einflüsse und aktive Profile – also genau die Stellen, an denen Versionskonflikte oft entstehen.

2. Updates durchführen

Variante A: direkt gesetzte Versionen

mvn versions:use-latest-releases

Variante B: Properties aktualisieren

mvn versions:update-properties

Beispielsweise von:

<junit.version>3.3.2</junit.version>

auf:

<junit.version>3.5.0</junit.version>

Parent-POM aktualisieren

mvn versions:update-parent

3. Nur sichere Updates ohne Major-Sprünge

Hier liegt der eigentliche Hebel für einen stabilen Alltag.

Nur Minor- und Patch-Updates zulassen

mvn versions:update-properties -DallowMajorUpdates=false
  • 5.1 → 5.9 erlaubt
  • 5.x → 6.x blockiert

Nur Patch-Updates zulassen

mvn versions:update-properties \
-DallowMajorUpdates=false \
-DallowMinorUpdates=false
  • 5.1.1 → 5.1.9 erlaubt
  • 5.1 → 5.2 blockiert

4. Sicherer Workflow für den Alltag

Ein bewährter Ablauf sieht so aus:

mvn versions:display-property-updates
mvn versions:display-plugin-updates
mvn versions:display-dependency-updates

Danach entscheidest Du Dich für eine Strategie:

Konservativ

mvn versions:update-properties -DallowMajorUpdates=false

Aggressiv

mvn versions:update-properties

Danach immer testen:

mvn clean test

5. Änderungen rückgängig machen

mvn versions:revert

Oder Änderungen dauerhaft übernehmen:

mvn versions:commit

6. Best Practices aus der Praxis

Versionen zentral über Properties steuern

<junit.version>3.5.4</junit.version>

Plugins konsistent referenzieren

<maven-surefire-plugin.version>3.5.4</maven-surefire-plugin.version>

Verwendung dann über:

${maven-surefire-plugin.version}

Regelmäßige Updates einplanen

  • monatlich prüfen
  • quartalsweise Major-Upgrades evaluieren

Fazit

Maven bringt alles mit, was Du für saubere Dependency-Pflege brauchst. Entscheidend ist nicht nur das Update selbst, sondern die Strategie dahinter: Properties nutzen, Major-Updates bewusst steuern und lieber regelmäßig prüfen als selten mit einem großen Big-Bang-Upgrade reagieren.

  • mehr Transparenz über veraltete Komponenten
  • automatisierte und steuerbare Updates
  • bessere Kontrolle über Stabilität und Risiko
Veröffentlicht am

Docker Container nach außen sichtbar machen

(Quelle: https://docs.docker.com/network/bridge/)

Nach einer frischen Dockerinstallation sind Docker-Container oft nicht von außen Erreichbar trotz der exposed Ports und der Portfreigabe im RUN-Aufruf.

Standardmäßig wird der Traffic der Default Bridge nicht nach außen weitergeleitet. Aus diesem Grund muss das Forwarding in den Einstellungen gesetzt werden durch zwei Kommandos:
Enable forwarding from Docker containers to the outside world

Konfiguriere den Linux-Kernel zum Erlauben des IP-Forwardings:$ sudo sysctl net.ipv4.conf.all.forwarding=1
Ändere die Richtlinie für iptables Weiterleitungen von Drop to Accept:$ sudo iptables -P FORWARD ACCEPT
Veröffentlicht am

Remotedesktop auf zwei von drei Bildschirmen einsetzen

In diesem Beitrag erkläre ich Euch, wie Ihr Eure Remotedesktopverbindung auf beliebige Monitore beschränken könnt. Im konkreten Beispiel auf zwei von dreien. Es geht aber auch eine beliebige andere Kombination – wichtig ist dass die Bildschirme aneinander angrenzen.

Ausgangslage

Vielleicht kennt ihr das seit dem Pandemiejahr 2020 im Homeoffice?
Wir auf Arbeit haben den Luxus, dass wir über die Firmentelefonanlage von zu Hause aus telefonieren können. Dafür haben wir die Telefoniesoftware auf dem heimischen PC installiert, arbeiten aber per Remote-Desktop auf den Büro-PC.

Jetzt habe ich aber das Geraffel, dass zum Annehmen, wählen und Auflegen von Telefongesprächen erst aus der Remoteumgebung raus auf den heimischen Rechner muss, um das Telefon zu bedienen.

Bisher hatte ich das so gelöst, dass ich entweder über alle Bildschirme eine RDP-Sitzung geöffnet hatte oder aber über nur einen. Zum Arbeiten im Büro benötige ich jedoch im Idealfall zwei Bildschirme. Warum also nicht die RDP-Sitzung auf zwei von drei Bildschirmen reduzieren?

Lösungsansatz

Ich erstelle eine RDP-Sitzung, in der ich den Haken für „Alle Monitore für Remotesitzung verwenden“ anhake.

Alle Monitore Verwenden ist anzuhaken, um sich mit allen Bildschirmen per RDP zu verbinden.

Statt mich zu verbinden, speichere ich die Verbindungseinstellung in eine Verbindungsdatei. Diese öffne ich mit einem Editor
Hier füge ich ganz unten eine Zeile an:

selectedmonitors:s:0,2

Hier könnt ihr mit den Zahlen hinter den Doppelpunkt die Bildschirmnummern (mit 0 aufsteigend) angeben, die ihr verwenden wollt.

Eingeben der Monitornummer wählt aus wo der RDP geöffnet wird.

Gegebenfalls müsst ihr mit den Zahlen etwas ausprobieren, bis ihr die richtige Bildschirmkombination gefunden habt. Nach einer Weile ausprobieren fand ich heraus, dass 0,2 für mein persönliches Monitor-Setup das richtige ist.
Ihr könnt zum Beispiel mit nur einer Zahl als Angabe erstmal testen, welcher Bildschirm welche Nummer hat, um Euch an das richtige Ergebnis heranzutasten.
Viel Erfolg!

Quelle: Computerbase

Veröffentlicht am

VBA Excel – Das Bild eine CommandButtons ändern

CommandButton Bild ändern

Ich habe eine Weile im Netz gesucht, bis ich auf einen hilfreichen Artikel gestoßen bin:

https://docs.microsoft.com/de-de/office/vba/api/office.commandbarbutton.picture

Hier ist der kopierte Codeschnipsel, wie ich das Bild eines CommandButtons zur Laufzeit in VBA (Excel) ändern kann:

Sub ChangeButtonImage() 
    Dim picPicture As IPictureDisp 
    Dim picMask As IPictureDisp 
 
    Set picPicture = stdole.StdFunctions.LoadPicture( _ 
        "c:\images\picture.bmp") 
    Set picMask = stdole.StdFunctions.LoadPicture( _ 
        "c:\images\mask.bmp") 
 
    'Reference the first button on the first command bar 
    'using a With...End With block. 
    With Application.CommandBars.FindControl(msoControlButton) 
        'Change the button image. 
        .Picture = picPicture 
 
        'Use the second image to define the area of the 
        'button that should be transparent. 
        .Mask = picMask 
    End With 
End Sub
Veröffentlicht am

JAVA Eclipse Access restriction: The constructor […] is not API (restriction on required library ‚C:\Program Files\Java\jre1.8.0_181\lib\ext\jfxrt.jar‘)

Völlig ohne Vorwarnung haben meine ganzen Java-Projekte diese Fehlermeldung erhalten:

Access restriction: The constructor  is not API (restriction on required library 'C:\Program Files\Java\jre1.8.0_181\lib\ext\jfxrt.jar')

Lösen ließ sich das ganz einfach. Das Projekt hatte sich als Java-Grundlage eine Runtime (JRE) und kein Development Kit (JDK) gewählt –> Das muss einfach wieder umsgestellt werden auf JDK.

Alternativ kann man die Berechtigung auch für das betroffene Projekt vergeben:

In ein Properties des Projekts

  • Java Build Path –> Libraries
  • Acess Rules –> Edit und Add
  • Als Wert „javafx/**“ (in meinem Fall) hinzufügen.

Anschließend Apply und Rebuild –> Problem gelöst 🙂