stevedlawrence commented on a change in pull request #178: Created Windows MSI
installer package.
URL: https://github.com/apache/incubator-daffodil/pull/178#discussion_r254893153
##########
File path: daffodil-cli/build.sbt
##########
@@ -71,3 +78,165 @@ rpmRelease := {
rpmLicense := Some(licenses.value.map { case (n: String, _) => n }.mkString("
and "))
rpmPrefix := Some(defaultLinuxInstallLocation.value)
+
+//
+// Windows configuration
+//
+
+//
+// Here we set the variables that are supported by the SBT WiX plug-in.
+// We also get fairly aggressive in editing/modifying the XML in order
+// to control and use some specific features that are supported by WiX
+// but which are not properly suported by the SBT plug-in. The changes
+// range from deleting an incorrect UI reference to adding whole files
+// to the body of code that is fed to the WiX compiler (candle) and
+// linker (light). We also change some attributes and such with a
+// ReWriter at the end. The comments should, at the very least, allow
+// you to follow the intent of each channge.
+//
+
+// Map variables from Universal as a starting point (default).
+mappings in Windows := (mappings in Universal).value
+
+// Force the correct installation directory name. This overwrites
+// 'daffodil-cli', which is the directory that we invoke sbt in.
+// The SBT WiX plug-in incorrectly assumes that the directory of
+// invocation is the same name as the direcotry you eventually
+// want to install into.
+name in Windows := "Daffodil"
+
+// The Windows packager SBT plug-in maps the maintainer variable into
+// the WiX ManufacturerFullName field. This is a very strange choice.
+// It also maps it to the manufacturer name in the installation
+// directory heirarchy. Among other things, this means it needs to be
+// short so as to not blow out the path length.
+maintainer in Windows := "Apache"
Review comment:
Could we instead do something like "Apache Daffodil Developers - dev AT
daffodil.apache.org to get around the @ issue?
Also, from my testing, the plugin only uses the ``maintainer in Windows``
property in three places:
1. Product Manufacturer attribute
1. Package Manuacturer attribute
1. RegistryValue Key attribute
It does not appear to affect where any files are installed. They are always
installed to ``C:\\Program Files\Apache\Daffodil\`` regardless.
I'd guess that 1 and 2 (the manufracturer attributes) are used in Add/Remove
programs or in the MSI file properties or something. In which case the
suggested change to maintainer seems like a good idea.
The change probably doesn't make sense for the RegistryValue Key attribute,
but I think you mentioned that the plugin does the wrong thing when setting
that up anyways. Maybe we should add another RewriteRule to fix that attribute
to use the correct thing registry Key, and let the Manufacturer be the correct
thing mentioning developers and email address.
Also, is it possible that the @ sign caused a problem in the ReistryValue
Key attribute, and it would be valid in the Manufacturer attributes, in which
case we could use the correct ``Apache Daffodil Developers
<[email protected]>`` string?
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
With regards,
Apache Git Services
