|
1 2 |
cd /usr/lib/jvm/adoptopenjdk-11-hotspot-amd64 sudo keytool -importcert -file '/path/to/my.cer' -keystore lib/security/cacerts -alias "myAlias" -trustcacerts -storepass changeit |
Obacht: Den Alias darf (sollte) man anpassen, aber das Passwort ist tatsächlich “changeit” 🙃
CustomAction führt ein Kommando aus, und das ist bspw. ein Shell-Befehl. In diesem Fall ein echo in eine Datei:
|
1 2 3 4 5 6 |
<CustomAction Id="echo_some_stuff" Directory="INSTALLDIR" Execute='deferred' Impersonate='no' ExeCommand='cmd.exe /s /c "echo foobar>>file.txt"' Return='check' /> |
Will man als Teil von “foobar” jetzt Sonderzeichen mit ausgeben, muss man XML-, WiX-/MSI-, und CMD-Escaping kombinieren – oder man hält sich einfach eine Waffe an den Kopf, das geht schneller:
Das Feature-Element hat einige UI-relevante Attribute, die nicht selbsterklärend sind:
Absent='disallow' schaltet “The feature will not be installed” aus – wie man für mandatorische Features das Dropdown insgesamt deaktiviert, weiß ich nicht. Ja, man kann das ganze Feature verstecken (Display='hidden'), aber nicht nur das Dropdown 🤷🏻♂️AllowAdvertise='no' schaltet “The feature will be installed when needed” ausEine Ersetzung:
|
1 2 3 4 5 |
task fooBar(type: Copy) { from file("${projectDir}/foo/bar.xml") into("${projectDir}/xy/z") filter { line -> line.replaceAll('someString', 'someReplacement') } } |
Mehrere Ersetzungen:
|
1 2 3 4 5 6 7 8 9 10 11 |
import org.apache.tools.ant.filters.ReplaceTokens task fooBar(type: Copy) { from file("${projectDir}/foo/bar.xml") into("${projectDir}/xy/z") filter(ReplaceTokens, tokens: [ // requires targets to be wrapped in '@', like '@someString@': 'someString' : 'someReplacement', 'someOtherString': 'someOtherReplacement', ]) } |
VBoxManage.exe: error: Error in (line 120) — Invalid value ‘VBOXSVGA’ in Display/@controller attribute.
Kann offenbar passieren, wenn eine VM unter Linux erstellt und dann unter Windows gestartet wird. Lösung: Die .ovf-Datei der VM öffnen, und
|
1 |
<Display controller="VBoxSVGA" VRAMSize="128"/> |
in
|
1 |
<Display VRAMSize="128"/> |
ändern. Beides von hier.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
Add-Type @" using System.Net; using System.Security.Cryptography.X509Certificates; public class TrustAllCertsPolicy : ICertificatePolicy { public bool CheckValidationResult( ServicePoint srvPoint, X509Certificate certificate, WebRequest request, int certificateProblem) { return true; } } "@ [System.Net.ServicePointManager]::CertificatePolicy = New-Object TrustAllCertsPolicy Invoke-WebRequest 'https://127.0.0.1:8444/my/endpoint' -OutFile 'c:\response.json' |
via. PS, in einem Vagrantfile so zu escapen – man beachte auch die Einrückungen:
|
1 2 3 4 5 6 7 |
config.vm.provision "disable cert validation callback", type: "shell", inline: <<-SHELL Add-Type @" ... "@ [System.Net.ServicePointManager]::CertificatePolicy = New-Object TrustAllCertsPolicy Invoke-WebRequest 'https://127.0.0.1:8444/my/endpoint' -OutFile 'c:\\response.json' SHELL |
HTH
Exclude set of tests (via) and/or categories:
|
1 2 3 4 5 6 7 8 9 |
task junitSystemTest(type: Test) { systemProperties = System.properties def runSeparately = ['**/FirstSpec*', '**/SecondSpec*'] useJUnit { includeCategories 'com.acme.SystemTest' exclude runSeparately } } |
Pass collection from shell (via, and):
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
// ./gradlew junitSystemTest -PexcludeTests=**/FirstSpec*,**/SecondSpec* task junitSystemTest(type: Test) { systemProperties = System.properties useJUnit { includeCategories 'com.acme.SystemTest' if (project.hasProperty('excludeTests')) { project.properties['excludeTests'].split(',').each { exclude it } } } } |
Run single test only (via):
|
1 |
./gradlew junitSystemTest --tests FirstSpec* |
Exclude all tests from build task:
|
1 |
./gradlew clean build -x test |
to be completed
Im Grunde geht’s sogar um zwei Themen, die beide relativ unklar sind, wenn man sich die Einträge auf Stack Overflow ansieht:
Bspw. hier, hier, hier, hier. Es gibt dort einige Lösungsvorschläge, mehr oder weniger aufwändig, viele für Spring Boot 1.x – hier eine weitere (für Spring Boot 2), imho sehr elegante (mit viel Input von Nils!):
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 |
@Component @WebEndpoint(id = "prettyhealth") public class PrettyHealthEndpoint { private final HealthEndpoint healthEndpoint; private final ObjectMapper objectMapper; @Autowired public PrettyHealthEndpoint(HealthEndpoint healthEndpoint, ObjectMapper objectMapper) { this.healthEndpoint = healthEndpoint; this.objectMapper = objectMapper; } @ReadOperation(produces = "application/json") public String getHealthJson() throws JsonProcessingException { Health health = healthEndpoint.health(); ObjectWriter writer = objectMapper.writerWithDefaultPrettyPrinter(); return writer.writeValueAsString(health); } @ReadOperation public String prettyHealth() throws JsonProcessingException { return "<html><body><pre>" + getHealthJson() + "</pre></body></html>"; } } |
Dann wird /health auf /internal/health (oder irgendwas) umgeleitet, und danach /prettyhealth auf /health:
|
1 2 3 4 |
# application.properties: management.endpoints.web.exposure.include=prettyhealth management.endpoints.web.path-mapping.health=internal/health management.endpoints.web.path-mapping.prettyhealth=/health |
et voilà.
tl;dr: MajorUpgrade ab der initialen Version!
Folgendes Szenario: Ich baue mit WiX einen MSI-Installer für meine Software. Die Software hat die Version 1.0. Nun möchte ich meine Software auf v1.1 upgraden. Was tun?
WiX bietet mehrere Möglichkeiten, namentlich “Major Upgrades”, “Minor Upgrades”, sowie “Small Updates”, die sich ungefähr so definieren:
Liest sich, als würde man meistens ein Minor Upgrade wollen. Internet sagt allerdings das Gegenteil, die Literatur* sieht Major Upgrades als “easier to implement than any other option” an, und last but not least empfiehlt WiX selbst:
When creating an .msi-based installer, you are strongly encouraged to include logic that supports Windows Installer major upgrades.
Was dabei nie so richtig, richtig klar wird (teilweise wird implizit das Gegenteil angedeutet): Beinhaltet nicht bereits Version 1.0 MajorUpgrade (sondern bspw. erst das erste Upgrade), dann funktioniert quasi nichts:
MajorUpgrade enthielt, wird von Upgrade/Downgrade-Logik komplett ignoriert!Warum das dann nicht mandatorisch ist, wird wohl Microsofts Geheimnis bleiben.
*Nick Ramirez, “WiX 3.6: A Developer’s Guide to Windows Installer XML”, Seite 342
Per default deinstalliert ein MajorUpgrade die alte Version und installiert dann die neue. Das kann problematisch sein, denn ein Upgrade (engl. für “Verbesserung”, “Aufrüstung”!) sollte ja bspw. Konfigurationsdaten usw. behalten. Da hilft das Scheduling-Attribut:
|
1 |
<MajorUpgrade Schedule="afterInstallExecute" DowngradeErrorMessage="A newer version of [ProductName] is already installed."/> |
sorgt dafür, dass bestehende Dateien (und in diesem Fall auch Services) erhalten bleiben. Es wird quasi definiert, wann das bestehende Produkt entfernt werden soll, und afterInstallExecute sagt “nach der Installation des Upgrades” – natürlich wird dann nur noch entfernt, was in v1.1 nicht mehr benötigt wird.
Achtung: Das setzt offenbar die Erkennung außer Kraft, die eine Neuinstallation derselben Version verhindert 🙄
Bestimmte Schritte des Installers sollen nur bei Erstinstallation ausgeführt werden (etwa die Konfiguration durch den User, die Installation eines Services, …). Dafür gibt es Conditions, bzw. verschiedene States, auf die man prüfen kann – und das ist ziemlich unübersichtlich. Ich beschränke mich an dieser Stelle auf einen Stackoverflow-Post, der gute, sprechende Aliase definiert:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
<SetProperty After="FindRelatedProducts" Id="FirstInstall" Value="true"> NOT Installed AND NOT WIX_UPGRADE_DETECTED AND NOT WIX_DOWNGRADE_DETECTED </SetProperty> <SetProperty After="SetFirstInstall" Id="Upgrading" Value="true"> WIX_UPGRADE_DETECTED AND NOT (REMOVE="ALL") </SetProperty> <SetProperty After="RemoveExistingProducts" Id="RemovingForUpgrade" Sequence="execute" Value="true"> (REMOVE="ALL") AND UPGRADINGPRODUCTCODE </SetProperty> <SetProperty After="SetUpgrading" Id="Uninstalling" Value="true"> Installed AND (REMOVE="ALL") AND NOT (WIX_UPGRADE_DETECTED OR UPGRADINGPRODUCTCODE) </SetProperty> <SetProperty After="SetUninstalling" Id="Maintenance" Value="true"> Installed AND NOT Upgrading AND NOT Uninstalling AND NOT UPGRADINGPRODUCTCODE </SetProperty> |
Ein Kind von Component sollte immer KeyPath="yes" gesetzt bekommen. Selbst, wenn es nur ein Kind gibt, aber insbesondere bei mehreren. Daran wird entscheiden, welches die maßgebliche Datei ist, die vorhanden (und aktuell) sein muss, um “muss (re-)installiert werden” zu entscheiden.