From b5cb2b48d17d114eece4c1bec2e1126eade5d2af Mon Sep 17 00:00:00 2001
From: Valery Kharseko <vharseko@3a-systems.ru>
Date: Sat, 05 Sep 2026 18:27:43 +0000
Subject: [PATCH] Modernize the Windows MSI: WiX v5, x64, upgrade from 5.1.x (#701)
---
pom.xml | 22 ++++++++++++++++++++++
1 files changed, 22 insertions(+), 0 deletions(-)
diff --git a/pom.xml b/pom.xml
index 23cdba7..d17e37b 100644
--- a/pom.xml
+++ b/pom.xml
@@ -341,6 +341,22 @@
<publishingServerId>ossrh</publishingServerId>
<autoPublish>true</autoPublish>
<waitMaxTime>5400</waitMaxTime>
+ <!-- The MSI modules stay in every reactor so that maven-release-plugin keeps
+ rewriting their versions (see the note in opendj-packages/pom.xml), but the
+ installer they build is distributed through GitHub Releases and the
+ Package/Deploy artifact, not Central - and only a Windows job can build it,
+ so the Linux release that publishes to Central has nothing but their poms to
+ offer. Excluded here rather than with maven.deploy.skip in the modules: the
+ extension above unbinds maven-deploy-plugin and publishes through this
+ plugin's own goal, which that property does not gate, so the poms would ship
+ to Central with no .msi beside them - a resolvable coordinate whose artifact
+ does not exist, which is worse for a consumer than a version that was never
+ published. The match is against the bare artifactId; a groupId:artifactId
+ entry would silently never match. -->
+ <excludeArtifacts>
+ <excludeArtifact>opendj-msi</excludeArtifact>
+ <excludeArtifact>opendj-msi-standard</excludeArtifact>
+ </excludeArtifacts>
</configuration>
</plugin>
</plugins>
@@ -619,6 +635,12 @@
</executions>
</plugin>
+ <plugin>
+ <groupId>org.codehaus.mojo</groupId>
+ <artifactId>exec-maven-plugin</artifactId>
+ <version>3.6.3</version>
+ </plugin>
+
<!-- Retrieve the build timestamp and SCM revision number -->
<plugin>
<groupId>org.codehaus.mojo</groupId>
--
Gitblit v1.10.0