Externalise OS/EE Hazelcast edition names (#1072)

The names of the editions of Hazelcast should not be hardcoded, to allow adjusting the edition names to suit business requirements, localization etc. I've updated references to `Open Source` and `Enterprise` to a key to an externalised value, where sensible. The actual names remain unchanged, as updating these terms is [larger than just this repo](https://hazelcast.slack.com/archives/C035HQET5/p1712585262831789?thread_ts=1712583856.778069&cid=C035HQET5). I've **not** done this for: - Code samples - URLs - Examples of Hazelcast outputs - Hazelcast configuration properties - Migration guides from older versions (e.g. IMDG, Jet) where the names can be hardcoded as they are correct _for that version_ - The `ENTERPRISE` suffix on EE-only pages (this is coming from CSS somewhere) - ![image](https://github.com/hazelcast/hz-docs/assets/8626721/9c419761-06e8-49fe-92ac-afc750e5c881) [Slack discussion](https://hazelcast.slack.com/archives/C035HQET5/p1712583856778069). --------- Co-authored-by: serdaro <[email protected]>
hazelcast · Apr 22, 2024 · df748c8 · df748c8
1 parent c9205fb
commit df748c8
Show file tree

Hide file tree

Showing 89 changed files with 207 additions and 204 deletions.
diff --git a/docs/antora.yml b/docs/antora.yml
@@ -29,5 +29,8 @@ asciidoc:
     page-latest-supported-python-client: '5.3.0'
     page-latest-supported-nodejs-client: '5.3.0'
     page-latest-supported-clc: '5.3.1'
+    open-source-product-name: 'Open Source'
+    enterprise-product-name: 'Enterprise'
+
 nav:
   - modules/ROOT/nav.adoc
diff --git a/docs/modules/ROOT/nav.adoc b/docs/modules/ROOT/nav.adoc
@@ -43,8 +43,8 @@ include::troubleshoot:partial$nav.adoc[]
 * Installation
 ** xref:deploy:choosing-a-deployment-option.adoc[]
 ** xref:getting-started:editions.adoc[Editions and Distributions]
-** xref:getting-started:install-hazelcast.adoc[Open Source]
-** xref:getting-started:install-enterprise.adoc[Enterprise]
+** xref:getting-started:install-hazelcast.adoc[{open-source-product-name}]
+** xref:getting-started:install-enterprise.adoc[{enterprise-product-name}]
 * Member/Client Discovery
 ** xref:clusters:discovery-mechanisms.adoc[]
 ** xref:clusters:discovering-by-tcp.adoc[]

diff --git a/docs/modules/ROOT/pages/capacity-planning.adoc b/docs/modules/ROOT/pages/capacity-planning.adoc
@@ -185,7 +185,7 @@ be sure to use a prime number of partitions. This helps minimize
 the collision of keys across partitions, ensuring more consistent lookup
 times.
 
-NOTE: If you are an Enterprise customer using the High-Density Memory Store
+NOTE: If you are an {enterprise-product-name} customer using the High-Density Memory Store
 with large data sizes, we recommend a large increase in partition count, starting with 5009 or higher.
 
 NOTE: The partition count cannot be easily changed after a cluster is created, so if you have a large cluster 

diff --git a/docs/modules/ROOT/pages/phone-homes.adoc b/docs/modules/ROOT/pages/phone-homes.adoc
@@ -69,8 +69,8 @@ The following information is sent in a phone home:
 ** FencedLocks count
 ** AtomicLongs count
 ** AtomicRefs count
-* Hazelcast Enterprise specific:
-** Flag for Hazelcast Enterprise
+* Hazelcast {enterprise-product-name} specific:
+** Flag for Hazelcast {enterprise-product-name}
 ** Hash value of license key
 ** Native memory usage
 ** Whether dynamic configuration persistence is enabled

diff --git a/docs/modules/ROOT/pages/production-checklist.adoc b/docs/modules/ROOT/pages/production-checklist.adoc
@@ -92,7 +92,7 @@ be large enough for a balanced data or task distribution so that each member
 does not manage too few partitions.
 * A partition size of 50MB or less typically ensures good performance. Larger clusters may be able to use up to 100MB partition sizes, but will likely also require larger JVM heap sizes to accomodate the increase in data flow.
 
-If you are a Hazelcast Enterprise customer using the High-Density Data Store with large data sizes,
+If you are a Hazelcast {enterprise-product-name} customer using the High-Density Data Store with large data sizes,
 we recommend a large increase in partition count, starting with 5009 or higher.
 
 The partition count cannot be easily changed after a cluster is created, so if you have a large cluster be sure to test and set an optimum partition count prior to deployment. If you need to change the partition count after a cluster is already running, you will need to schedule a maintenance window to entirely bring the cluster down. If your cluster uses the xref:storage:persistence.adoc[Persistence] or xref:cp-subsystem:persistence.adoc[CP Persistence] features, those persistent files will need to be removed after the cluster is shut down, as they contain references to the previous partition count. Once all member configurations are updated, and any persistent data structure files are removed, the cluster can be safely restarted.
diff --git a/docs/modules/clients/pages/java.adoc b/docs/modules/clients/pages/java.adoc
@@ -7,10 +7,10 @@
 To get started, include the `hazelcast.jar` dependency in your classpath. Once included, you can start using this client as if
 you are using the Hazelcast API. The differences are discussed in the below sections.
 
-NOTE: If you have a Hazelcast Enterprise license, you do not need to set the license key in your Hazelcast Java clients to use the xref:getting-started:editions.adoc#features-in-hazelcast-enterprise[enterprise features] - setting it on the member side is enough. In this case, you only need to include the `hazelcast-enterprise.jar` dependency in your classpath.
+NOTE: If you have a Hazelcast {enterprise-product-name} license, you do not need to set the license key in your Hazelcast Java clients to use the xref:getting-started:editions.adoc#features-in-hazelcast-enterprise[{enterprise-product-name} features] - setting it on the member side is enough. In this case, you only need to include the `hazelcast-enterprise.jar` dependency in your classpath.
 
 If you prefer to use Maven, simply add the `hazelcast` dependency
-to your `pom.xml` (or the `hazelcast-enterprise` dependency, if you want the client to use enterprise features provided that you have the Hazelcast Enterprise license),
+to your `pom.xml` (or the `hazelcast-enterprise` dependency, if you want the client to use {enterprise-product-name} features provided that you have the Hazelcast {enterprise-product-name} license),
 which you may already have done to start using Hazelcast:
 
 [source,xml,subs="attributes+"]
@@ -949,7 +949,7 @@ Its default value is *5000* milliseconds.
 
 ==== Setting a Socket Interceptor
 
-[blue]*Hazelcast Enterprise*
+[blue]*Hazelcast {enterprise-product-name}*
 
 Following is a client configuration to set a socket intercepter.
 Any class implementing `com.hazelcast.nio.SocketInterceptor` is a socket interceptor.
@@ -1025,7 +1025,7 @@ socketOptions.setBufferSize(32)
 
 ==== Enabling Client TLS/SSL
 
-[blue]*Hazelcast Enterprise*
+[blue]*Hazelcast {enterprise-product-name}*
 
 You can use TLS/SSL to secure the connection between the client and the members.
 If you want TLS/SSL enabled for the client-cluster connection, you should set `SSLConfig`.
@@ -1528,7 +1528,7 @@ and for each connection we have a connection timeout; see the
 
 === Blue-Green Deployment
 [[blue-green-mechanism]]
-[blue]*Hazelcast Enterprise Feature*
+[blue]*Hazelcast {enterprise-product-name} Feature*
 
 Blue-green deployment refers to a client connection technique that reduces system downtime by deploying two mirrored clusters: blue (active) and green (idle). One of these clusters is running in production while the other is on standby.
 
@@ -2392,9 +2392,9 @@ If both are configured, this one is ignored.
 
 == Using High-Density Memory Store with Java Client
 
-[navy]*Hazelcast Enterprise*
+[navy]*Hazelcast {enterprise-product-name}*
 
-If you have [navy]*Hazelcast Enterprise*, your Hazelcast Java client's Near Cache
+If you have [navy]*Hazelcast {enterprise-product-name}*, your Hazelcast Java client's Near Cache
 can benefit from the High-Density Memory Store.
 
 Let's recall the Java client's Near Cache configuration

diff --git a/docs/modules/cluster-performance/pages/best-practices.adoc b/docs/modules/cluster-performance/pages/best-practices.adoc
@@ -408,7 +408,7 @@ Note that a map's in-memory format can be different from that of its Near Cache.
 ** `BINARY`: Data is stored in serialized binary format (default value).
 ** `OBJECT`: Data is stored in deserialized form.
 ** `NATIVE`: Data is stored in the Near Cache that uses Hazelcast's High-Density Memory Store feature.
-This option is available only in Hazelcast Enterprise. Note that a map and
+This option is available only in Hazelcast {enterprise-product-name}. Note that a map and
 its Near Cache can independently use High-Density Memory Store.
 For example, while your map does not use High-Density Memory Store, its Near Cache can use it.
 * `invalidate-on-change`: Specifies whether the cached entries are evicted when the entries are updated or removed.
@@ -432,16 +432,16 @@ You still can combine it with `time-to-live-seconds` and `max-idle-seconds` to e
 *** `ENTRY_COUNT`: Maximum size based on the entry count in the Near Cache (default value).
 *** `USED_NATIVE_MEMORY_SIZE`: Maximum used native memory size of the specified Near Cache in MB to trigger the eviction.
 If the used native memory size exceeds this threshold, the eviction is triggered. 
-Available only for `NATIVE` in-memory format. This is supported only by Hazelcast Enterprise.
+Available only for `NATIVE` in-memory format. This is supported only by Hazelcast {enterprise-product-name}.
 *** `USED_NATIVE_MEMORY_PERCENTAGE`: Maximum used native memory percentage of the specified Near Cache to trigger the eviction.
 If the native memory usage percentage (relative to maximum native memory size) exceeds this threshold, the eviction is triggered.
-Available only for `NATIVE` in-memory format. This is supported only by Hazelcast Enterprise.
+Available only for `NATIVE` in-memory format. This is supported only by Hazelcast {enterprise-product-name}.
 *** `FREE_NATIVE_MEMORY_SIZE`: Minimum free native memory size of the specified Near Cache in MB to trigger the eviction.
 If free native memory size goes below this threshold, eviction is triggered. Available only for `NATIVE` in-memory format.
-This is supported only by Hazelcast Enterprise.
+This is supported only by Hazelcast {enterprise-product-name}.
 *** `FREE_NATIVE_MEMORY_PERCENTAGE`: Minimum free native memory percentage of the specified Near Cache to trigger eviction.
 If free native memory percentage (relative to maximum native memory size) goes below this threshold, eviction is triggered.
-Available only for `NATIVE` in-memory format. This is supported only by Hazelcast Enterprise.
+Available only for `NATIVE` in-memory format. This is supported only by Hazelcast {enterprise-product-name}.
 ** `size`: Maximum size of the Near Cache used for `max-size-policy`. When this is reached the Near Cache is evicted based on
 the policy defined. Any integer between `1` and `Integer.MAX_VALUE`. This value has different defaults, depending on the data structure.
 *** `IMap`: Its default value is `Integer.MAX_VALUE` for on-heap maps and `10000` for the `NATIVE` in-memory format.
@@ -679,7 +679,7 @@ ClientConfig clientConfig = new ClientConfig()
 
 ==== Example for Near Cache with High-Density Memory Store
 
-[navy]*Hazelcast Enterprise Feature*
+[navy]*Hazelcast {enterprise-product-name} Feature*
 
 The following is a configuration example for an IMap High-Density Near Cache for a Hazelcast member.
 

diff --git a/docs/modules/cluster-performance/pages/performance-tuning.adoc b/docs/modules/cluster-performance/pages/performance-tuning.adoc
@@ -162,7 +162,7 @@ latency, high transaction rates, large working memory, and/or consistent
 response times. Zulu and Zulu Enterprise are Azul’s certified, freely available
 open source builds of OpenJDK with a variety of flexible support options,
 available in configurations for the enterprise as well as custom and embedded systems. 
-Azul Zing is certified and supported in Hazelcast Enterprise. When deployed with Zing,
+Azul Zing is certified and supported in Hazelcast {enterprise-product-name}. When deployed with Zing,
 Hazelcast gains performance, capacity, and operational efficiency within the same infrastructure.
 Additionally, you can directly use Hazelcast with Zulu without making any changes to your code.
 
@@ -462,7 +462,7 @@ instead of the JVM heap. This allows you to keep data in the memory without
 incurring the overhead of garbage collection (GC). HDMS capabilities are supported by
 the map structure, JCache implementation, Near Cache, Hibernate caching, and Web Session replications.
 
-Available to Hazelcast Enterprise customers, HDMS is an ideal solution
+Available to Hazelcast {enterprise-product-name} customers, HDMS is an ideal solution
 for those who want the performance of in-memory data, need the predictability
 of well-behaved Java memory management, and don’t want to spend time
 and effort on meticulous and fragile GC tuning.

diff --git a/docs/modules/clusters/pages/discovery-mechanisms.adoc b/docs/modules/clusters/pages/discovery-mechanisms.adoc
@@ -89,7 +89,7 @@ discovering with multicast does not work.
 
 == Hazelcast for Kubernetes
 
-You can deploy a Hazelcast cluster to Kubernetes using Helm or xref:deploy:deploying-with-operator[Hazelcast Enterprise Operator].
+You can deploy a Hazelcast cluster to Kubernetes using Helm or xref:deploy:deploying-with-operator[Hazelcast {enterprise-product-name} Operator].
 See the xref:kubernetes:deploying-in-kubernetes.adoc[Deploying in Kubernetes section].
 
 

diff --git a/docs/modules/clusters/pages/legacy-ucd.adoc b/docs/modules/clusters/pages/legacy-ucd.adoc
@@ -3,11 +3,11 @@
 
 {description}
 
-{ucn} is only available to Enterprise Edition users.
+{ucn} is only available to {enterprise-product-name} Edition users.
 
-Hazelcast recommends that Enterprise Edition users migrate to {ucn} to benefit from the improved and extended capabilities that it offers.
+Hazelcast recommends that {enterprise-product-name} Edition users migrate to {ucn} to benefit from the improved and extended capabilities that it offers.
 
-After the next major release, Open Source users can either upgrade to Enterprise Edition, or add their resources to the Hazelcast member class paths.
+After the next major release, {open-source-product-name} users can either upgrade to {enterprise-product-name} Edition, or add their resources to the Hazelcast member class paths.
 
 For further information on migrating from {ucd} to {ucn}, see the xref:clusters:ucn-migrate-ucd.adoc[] topic.
 

diff --git a/docs/modules/clusters/pages/ucn-migrate-ucd.adoc b/docs/modules/clusters/pages/ucn-migrate-ucd.adoc
@@ -1,5 +1,5 @@
 = Migrate from {ucd}
-:description: {ucn} improves and extends the capabilities of {ucd} and is applicable to more use cases. Hazelcast recommends that Enterprise Edition users deprecate their {ucd} implementations and migrate to using {ucn}.
+:description: {ucn} improves and extends the capabilities of {ucd} and is applicable to more use cases. Hazelcast recommends that {enterprise-product-name} Edition users deprecate their {ucd} implementations and migrate to using {ucn}.
 :page-enterprise: true
 :page-beta: false
 

diff --git a/docs/modules/clusters/partials/ucn-migrate-tip.adoc b/docs/modules/clusters/partials/ucn-migrate-tip.adoc
@@ -1 +1 @@
-CAUTION: {ucd} has been deprecated and will be removed in the next major version. To continue deploying your user code after this time, Open Source users can either upgrade to Enterprise Edition, or add their resources to the Hazelcast member class paths. Hazelcast recommends that Enterprise users migrate their user code to use {ucn}. For further information on migrating from {ucd} to {ucn}, see the xref:clusters:ucn-migrate-ucd.adoc[] topic.
+CAUTION: {ucd} has been deprecated and will be removed in the next major version. To continue deploying your user code after this time, {open-source-product-name} users can either upgrade to {enterprise-product-name} Edition, or add their resources to the Hazelcast member class paths. Hazelcast recommends that {enterprise-product-name} users migrate their user code to use {ucn}. For further information on migrating from {ucd} to {ucn}, see the xref:clusters:ucn-migrate-ucd.adoc[] topic.
diff --git a/docs/modules/configuration/pages/dynamic-config-persistence.adoc b/docs/modules/configuration/pages/dynamic-config-persistence.adoc
@@ -38,7 +38,7 @@ If you use Kubernetes, *do not configure persistence for dynamic configuration*.
 See xref:dynamic-config.adoc#persistence[Persisting Dynamic Configuration in Kubernetes].
 
 == Enabling Persistence
-[.enterprise]*Enterprise*
+[.enterprise]*{enterprise-product-name}*
 
 By default, persistence for dynamic configuration changes is disabled on all clusters. To start persisting changes on disk, you must first enable the feature on the member.
 
@@ -73,7 +73,7 @@ hazelcast:
 
 [[backup]]
 == Creating Backups of the Configuration File
-[.enterprise]*Enterprise*
+[.enterprise]*{enterprise-product-name}*
 
 By default, Hazelcast keeps 5 backups of the configuration file in the member's startup directory.
 
@@ -125,13 +125,13 @@ Use the following configuration options to configure dynamic configuration for a
 |dynamic-configuration
 | Root configuration
 
-a| `persistence-enabled` [.enterprise]*Enterprise*
+a| `persistence-enabled` [.enterprise]*{enterprise-product-name}*
 | Whether changes made in dynamic configuration are persisted to a configuration file. Default: false.
 
-a| `backup-dir` [.enterprise]*Enterprise*
+a| `backup-dir` [.enterprise]*{enterprise-product-name}*
 | Relative or absolute path to a directory in which to store backups of the configuration file. Each new backup will be created inside this directory. Default: A new directory called `dynamic-configuration-backups` is created in the member's startup directory.                            
 
-a| `backup-count` [.enterprise]*Enterprise*
+a| `backup-count` [.enterprise]*{enterprise-product-name}*
 | Number of backups of the configuration file to keep. To disable backups, set this option to 0. Default: 5.
 |===
 

diff --git a/docs/modules/configuration/pages/dynamic-config.adoc b/docs/modules/configuration/pages/dynamic-config.adoc
@@ -1,5 +1,5 @@
 = Dynamic Configuration for Members
-:description: You can use dynamic configuration to add new configuration to members at runtime or update some supported configuration such as Enterprise license keys. This feature is useful if you want to configure a running cluster without having to restart the members.
+:description: You can use dynamic configuration to add new configuration to members at runtime or update some supported configuration such as {enterprise-product-name} license keys. This feature is useful if you want to configure a running cluster without having to restart the members.
 :keywords: dynamic configuration, update configuration
 
 {description}
@@ -19,7 +19,7 @@ include::clients:partial$rest-deprecation.adoc[]
 
 These options support different dynamic configuration changes, and not all changes support <<persistence, persistence>>. See the following table for what's available with each option.
 
-NOTE: To use the REST endpoints you need an Enterprise license.
+NOTE: To use the REST endpoints you need an {enterprise-product-name} license.
 
 .Supported dynamic configuration options
 |===
@@ -41,7 +41,7 @@ NOTE: To use the REST endpoints you need an Enterprise license.
 | xref:{page-latest-supported-mc}@management-center:clusters:update-config.adoc[Yes]
 | <<persistence, Yes>>
 
-| Update a Hazelcast Enterprise license
+| Update a Hazelcast {enterprise-product-name} license
 | No
 | xref:deploy:enterprise-licenses.adoc#update[Yes]
 | xref:dynamic-config-update-and-reload.adoc[Yes]

diff --git a/docs/modules/configuration/pages/jet-configuration.adoc b/docs/modules/configuration/pages/jet-configuration.adoc
@@ -136,7 +136,7 @@ joins the cluster. It has no effect on jobs with auto-scaling disabled.
 With this feature, you can restart the whole cluster without losing the
 jobs and their state. It is implemented on top of Hazelcast's Persistence
 feature, which persists the data to disk. You need to have
-the Hazelcast Enterprise edition and configure Hazelcast's Persistence to
+the Hazelcast {enterprise-product-name} edition and configure Hazelcast's Persistence to
 use this feature. The default value is `false`, i.e., disabled.
 
 |`max-processor-accumulated-records`

diff --git a/docs/modules/cp-subsystem/pages/configuration.adoc b/docs/modules/cp-subsystem/pages/configuration.adoc
@@ -65,7 +65,7 @@ NOTE: Running clusters must be restarted before any configuration changes take e
 
 [[persistence]]
 == Persisting CP Data Structures
-[.enterprise]*Enterprise*
+[.enterprise]*{enterprise-product-name}*
 
 To enable xref:cp-subsystem:cp-subsystem.adoc#persistence[CP Subsystem Persistence], set the <<persistence-enabled, `persistence-enabled`>> option to `true`.
 
@@ -474,7 +474,7 @@ config.getCPSubsystemConfig()
 --
 ====
 
-|[[persistence-enabled]]`persistence-enabled` [.enterprise]*Enterprise*
+|[[persistence-enabled]]`persistence-enabled` [.enterprise]*{enterprise-product-name}*
 |Whether <<persistence, CP Subsystem Persistence>> is globally
 enabled for CP groups created in the CP Subsystem. If enabled, CP members persist
 their local CP data to stable storage and can recover from crashes.

diff --git a/docs/modules/cp-subsystem/pages/cp-subsystem.adoc b/docs/modules/cp-subsystem/pages/cp-subsystem.adoc
@@ -183,7 +183,7 @@ CP members. This flexibility provides a good degree of fault tolerance at
 runtime.
 
 === Persistence
-[.enterprise]*Enterprise*
+[.enterprise]*{enterprise-product-name}*
 
 By default, CP Subsystem works in memory without persisting any state
 to disk. As a result, a crashed CP member cannot recover by