Fix Sculptor links

stefan-ka · stefan-ka · commit 67b0748b6f51 · 2024-10-29T09:35:43.000+01:00
diff --git a/_docs/faqs.md b/_docs/faqs.md
@@ -22,7 +22,7 @@ Have a look at our [CML Reference - Introduction](/docs/language-reference/) pag
 Have a look at the page [Language Semantic Model](/docs/language-model/). It introduces the semantic model of our DSL and lists the implemented semantic checkers.
 
 ### Where do I find a documentation regarding the tactic DDD syntax to specify a Bounded Context in detail?
-The tactic DDD part of our DSL is based on the [Sculptor DSL](http://sculptorgenerator.org/). We provide a short introduction and examples how you can detail your bounded contexts on the pages [Aggregate](/docs/aggregate/) and [Tactic DDD Syntax](/docs/tactic-ddd/). If you are interested in more details and all features, we refer to the [Sculptor documentation](http://sculptorgenerator.org/documentation/advanced-tutorial).
+The tactic DDD part of our DSL is based on the [Sculptor DSL](https://sculptor.github.io/). We provide a short introduction and examples how you can detail your bounded contexts on the pages [Aggregate](/docs/aggregate/) and [Tactic DDD Syntax](/docs/tactic-ddd/). If you are interested in more details and all features, we refer to the [Sculptor documentation](https://sculptor.github.io/documentation/advanced-tutorial).
 
 ### Which transformations can I apply to my CML model? Which generators are available?
 Currently you can generate [Microservice Domain-Specific Language (MDSL)](https://microservice-api-patterns.github.io/MDSL-Specification/) (micro-)service contracts providing assistance regarding how your system can be implemented in an (micro-)service-oriented architecture, [Service Cutter](http://servicecutter.github.io/) input  to get suggestions for service cuts or new bounded context, and you can generate UML ([PlantUML](http://plantuml.com/)) diagrams out of your CML. The following pages explain the generators in detail:
@@ -38,7 +38,7 @@ The Context Mapper tool provides a set of [architectural refactorings](https://s
 available refactorings [here](/docs/architectural-refactorings).
 
 ### Does Context Mapper support Event Sourcing and CQRS?
-The concepts behind event sourcing and CQRS do not require special modeling objects other than _DomainEvents_, which are supported by the Context Mapper DSL (CML). The syntax to specify the domain models within Bounded Contexts is based on [Sculptor](http://sculptorgenerator.org/) which supports event-driven concepts. 
+The concepts behind event sourcing and CQRS do not require special modeling objects other than _DomainEvents_, which are supported by the Context Mapper DSL (CML). The syntax to specify the domain models within Bounded Contexts is based on [Sculptor](https://sculptor.github.io/) which supports event-driven concepts. 
 Have a look at our [Event Sourcing and CQRS Modeling in Context Mapper](/docs/event-sourcing-and-cqrs-modeling/) tutorial to learn how to model events in CML.  
 
 ### Can I use Context Mapper to document Event Stormings?
diff --git a/_docs/generators/generic-freemarker-generator.md b/_docs/generators/generic-freemarker-generator.md
@@ -446,7 +446,7 @@ The meta-model behind CML contains a few inheritance hierarchies which make it u
 
 ### Get Type String of _ComplexType_
 If you work on the tactic DDD level with attributes and methods (parameters and return types) you may want to render the type of an attribute, parameter, or return type.
-This part of the DSL is based on [Sculptor](http://sculptorgenerator.org/), and the types are typically instances of the 
+This part of the DSL is based on [Sculptor](https://sculptor.github.io/), and the types are typically instances of the 
 [ComplexType](https://www.javadoc.io/doc/org.contextmapper/context-mapper-dsl/latest/org/contextmapper/tactic/dsl/tacticdsl/ComplexType.html) object. Depending on if it is primitive type or a reference to another type, rendering the type as a string is quite cumbersome. The function _getType_ which takes a 
 [ComplexType](https://www.javadoc.io/doc/org.contextmapper/context-mapper-dsl/latest/org/contextmapper/tactic/dsl/tacticdsl/ComplexType.html) as a parameter returns a simple string representing the type:
 
diff --git a/_docs/language-reference/aggregate.md b/_docs/language-reference/aggregate.md
@@ -3,15 +3,15 @@ title: Aggregate
 permalink: /docs/aggregate/
 ---
 
-The Aggregate pattern implementation from [Sculptor](http://sculptorgenerator.org/) has been adapted within CML to represent it with a separate grammar rule. 
+The Aggregate pattern implementation from [Sculptor](https://sculptor.github.io/) has been adapted within CML to represent it with a separate grammar rule. 
 
 For a short introduction to the syntax of the other tactic DDD patterns, please have a look at [Tactic DDD Syntax](/docs/tactic-ddd/). 
-For more details, we refer to the [Sculptor project](http://sculptorgenerator.org/) and its [documentation](http://sculptorgenerator.org/documentation/advanced-tutorial).
+For more details, we refer to the [Sculptor project](https://sculptor.github.io/) and its [documentation](https://sculptor.github.io/documentation/advanced-tutorial).
 
 ## Syntax
 The aggregate supports the [Responsibility Layers](/docs/responsibility-layers/) pattern and the [Knowledge Level](/docs/knowledge-level) pattern. An aggregate can further 
 contain Services, Resources, Consumers and SimpleDomainObjects (Entities, Value Objects, Domain Events, etc.) which are not further introduced here. 
-The respective rules are defined by the [Sculptor DSL](http://sculptorgenerator.org/), as already mentioned. 
+The respective rules are defined by the [Sculptor DSL](https://sculptor.github.io/), as already mentioned. 
 
 The following CML snippet illustrates an example of an aggregate to provide an impression how the rule can be used:
 
diff --git a/_docs/language-reference/bounded-context.md b/_docs/language-reference/bounded-context.md
@@ -136,10 +136,10 @@ If your bounded context is of the type TEAM, you can specify which bounded conte
 
 
 ## The Bounded Context Building Blocks
-Within a bounded context, you can create _Modules_ and _Aggregates_ as illustrated in the example at the beginning of this page. On this tactical DDD level we integrated the [Sculptor DSL](http://sculptorgenerator.org/).
-This means within a module and an aggregate you can use all the [Sculptor features](http://sculptorgenerator.org/documentation/advanced-tutorial) to specify your bounded context, such as Entities, Value Objects, Domain Events, Services, Repositories, etc.
+Within a bounded context, you can create _Modules_ and _Aggregates_ as illustrated in the example at the beginning of this page. On this tactical DDD level we integrated the [Sculptor DSL](https://sculptor.github.io/).
+This means within a module and an aggregate you can use all the [Sculptor features](https://sculptor.github.io/documentation/advanced-tutorial) to specify your bounded context, such as Entities, Value Objects, Domain Events, Services, Repositories, etc.
 
-Use the [Sculptor Documentation](http://sculptorgenerator.org/documentation/advanced-tutorial) and our [examples](https://github.com/ContextMapper/context-mapper-examples) to find out how you specify your bounded context.
+Use the [Sculptor Documentation](https://sculptor.github.io/documentation/advanced-tutorial) and our [examples](https://github.com/ContextMapper/context-mapper-examples) to find out how you specify your bounded context.
 Note that the Aggregate pattern is the only tactical DDD pattern where we changed the Sculptor syntax and adapted it to our interpretation and requirements. See [Aggregate](/docs/aggregate/).
 
 ## Semantic Rules
diff --git a/_docs/language-reference/language-reference.md b/_docs/language-reference/language-reference.md
@@ -34,7 +34,7 @@ The syntax and semantic rules of all the patterns are documented on their indivi
  
 ## Tactic DDD Patterns
 The tactic DDD part of the CML language(all grammar rules inside *Aggregates*s that is), are based on the [Sculptor DSL](https://github.com/sculptor/sculptor). 
-Thus, we refer to the [Sculptor documentation](http://sculptorgenerator.org/documentation/advanced-tutorial#domain-driven-design) for details regarding the tactic DDD patterns.
+Thus, we refer to the [Sculptor documentation](https://sculptor.github.io/documentation/advanced-tutorial#domain-driven-design) for details regarding the tactic DDD patterns.
  
 The most important tactic DDD patterns that we use in our [transformations (for instance, plantUML generation)](/docs/generators/generators) are the following:
  
diff --git a/_docs/language-reference/subdomain.md b/_docs/language-reference/subdomain.md
@@ -80,8 +80,8 @@ With the _domainVisionStatement_ keyword you can specify a vision statement for
 pattern.
 
 ### Entities
-In order to provide further details about your subdomain and which domain objects are part of it, you can use entities within a subdomain. Note that the used _Entity_ rule is integrated from the [Sculptor DSL](http://sculptorgenerator.org/). 
-For more details about the features and possibilities of this Entity rule, we refer to the [Sculptor documentation](http://sculptorgenerator.org/documentation/advanced-tutorial).
+In order to provide further details about your subdomain and which domain objects are part of it, you can use entities within a subdomain. Note that the used _Entity_ rule is integrated from the [Sculptor DSL](https://sculptor.github.io/). 
+For more details about the features and possibilities of this Entity rule, we refer to the [Sculptor documentation](https://sculptor.github.io/documentation/advanced-tutorial).
 An example of a simple entity with attributes is illustrated above.
 
 <div class="alert alert-custom">
diff --git a/_docs/language-reference/tactic-ddd.md b/_docs/language-reference/tactic-ddd.md
@@ -3,7 +3,7 @@ title: Tactic DDD Syntax
 permalink: /docs/tactic-ddd/
 ---
 
-The Context Mapper syntax for the tactic DDD part is based on the [Sculptor DSL](http://sculptorgenerator.org/). For this reason we do not document all details of the tactic language part, since all the information can be found in Sculptor's [documentation](http://sculptorgenerator.org/documentation/advanced-tutorial).
+The Context Mapper syntax for the tactic DDD part is based on the [Sculptor DSL](https://sculptor.github.io/). For this reason we do not document all details of the tactic language part, since all the information can be found in Sculptor's [documentation](https://sculptor.github.io/documentation/advanced-tutorial).
 However, we still provide a short introduction into the most important elements on this page.
 
 ## Aggregates
@@ -192,4 +192,4 @@ the example below. These methods/operations are declared exactly the same way as
 </pre></div>
 
 ## More Details about the Tactic DDD Syntax
-If you want to read more details about the syntax of the tactic DDD part within bounded contexts, we refer to the [Sculptor documentation](http://sculptorgenerator.org/documentation/advanced-tutorial).
+If you want to read more details about the syntax of the tactic DDD part within bounded contexts, we refer to the [Sculptor documentation](https://sculptor.github.io/documentation/advanced-tutorial).
diff --git a/_docs/modeling-tools/rapid-ooad.md b/_docs/modeling-tools/rapid-ooad.md
@@ -296,7 +296,7 @@ You can model application architectures with more than two subsystems by applyin
 Once you derived your initial Bounded Contexts, you can:
 
  - Add more details to the domain models (attributes, operations, services, repositories, etc.)
-   - [Here](/docs/tactic-ddd/) you can find a quick introduction into the tactic DDD syntax (based on [Sculptor](http://sculptorgenerator.org/)).
+   - [Here](/docs/tactic-ddd/) you can find a quick introduction into the tactic DDD syntax (based on [Sculptor](https://sculptor.github.io/)).
  - Refine and refactor them by using our [Architectural Refactorings](/docs/architectural-refactorings/).
  - Define a [Context Map](/docs/context-map/) that specifies the relationships between your Bounded Contexts.
  - [Generate](/docs/generators/) output and other representations of you CML model:
diff --git a/_docs/tutorials/event-sourcing-and-cqrs-modeling.md b/_docs/tutorials/event-sourcing-and-cqrs-modeling.md
@@ -22,10 +22,10 @@ If you are not fully familiar with the concepts of event sourcing and CQRS yet,
 ### Context and Objectives 
 This tutorial highlights the [Context Mapper DSL (CML)](/docs/language-reference/) concepts that support a) modeling event-sourced systems and b) CQRS. 
 
-Within CML Bounded Contexts and Aggregates, we integrated the [Sculptor DSL for tactic DDD](http://sculptorgenerator.org/) that allows domain-driven designers to specify the domain model of Bounded Contexts. This tutorial features this DSL.
+Within CML Bounded Contexts and Aggregates, we integrated the [Sculptor DSL for tactic DDD](https://sculptor.github.io/) that allows domain-driven designers to specify the domain model of Bounded Contexts. This tutorial features this DSL.
 
 ### Events
-As explained in the [Sculptor documentation](http://sculptorgenerator.org/documentation/event-driven-tutorial), the syntax of Sculptor supports modeling events.
+As explained in the [Sculptor documentation](https://sculptor.github.io/documentation/event-driven-tutorial), the syntax of Sculptor supports modeling events.
 
 A domain event is something that happened that affects the application/resource state. [Michael Plöd](https://speakerdeck.com/mploed/event-sourcing-workshop-at-software-architecture-summit-2016)
 suggests that the scope of domain events should always be based on Aggregates. The names of domain events shall indicate that the event happened in the past. 
@@ -102,7 +102,7 @@ Service CustomerQueryService {
 }
 ```
 
-Additionally, Sculptor introduces so-called *command events* to support CQRS explicitly (described [here](http://sculptorgenerator.org/documentation/event-driven-tutorial#commandevent)).
+Additionally, Sculptor introduces so-called *command events* to support CQRS explicitly (described [here](https://sculptor.github.io/documentation/event-driven-tutorial#commandevent)).
 In comparison to a domain event which describes something that has happened, a command event is something that the system is asked to perform. The following CML/Sculptor snippet illustrates an example how to model command events:
 
 ```text
@@ -149,8 +149,8 @@ to separate the read model (Aggregate) from the command model Aggregate.
 *Note:* The two Aggregates representing the command model and the read model should probably be contained in the same Bounded Context; otherwise, two Bounded Contexts have to access a shared database, which is considered a microservices antipattern.  
 
 ### Event Sourcing with Sculptor
-The [Sculptor generator](http://sculptorgenerator.org) further supports event sourcing specifically as described here: 
-[Event Sourcing with Sculptor](http://sculptorgenerator.org/2010/10/28/event-sourcing-with-sculptor). 
+The [Sculptor generator](https://sculptor.github.io/) further supports event sourcing specifically as described here: 
+[Event Sourcing with Sculptor](https://sculptor.github.io/2010/10/28/event-sourcing-with-sculptor). 
 However, the DSL syntax itself does not need additional concepts to support it. It is based on the _DomainEvents_, _Repositories_, and _Services_ provided by the Sculptor and also CML.
   * *Note:* We only used the Sculptor syntax for the tactic DDD grammar of our CML language. Using the Sculptor generator in Context Mapper is currently not supported.
 
diff --git a/_docs/tutorials/event-storming.md b/_docs/tutorials/event-storming.md
@@ -55,7 +55,7 @@ The following examples and modeling suggestions are based on the Event Storming
 
 ### Domain Events
 The domain events are typically the first objects that are discovered in an Event Storming.
-The tactic DDD syntax of CML is based on the [Sculptor DSL](http://sculptorgenerator.org/), which [supports event-driven concepts](http://sculptorgenerator.org/documentation/event-driven-tutorial). 
+The tactic DDD syntax of CML is based on the [Sculptor DSL](https://sculptor.github.io/), which [supports event-driven concepts](https://sculptor.github.io/documentation/event-driven-tutorial). 
 Hence, you can model _DomainEvents_ within your Aggregates.
 The following examples illustrate how we modeled the domain events from our Event Storming for Lakeside Mutual:
 
@@ -173,7 +173,7 @@ BoundedContext ClaimsManagement {
 ```
 
 ### User Roles
-At present, there is no concept of a user role in the Context Mapper DSL; however, we used [Sculptor](http://sculptorgenerator.org/)'s `doc` comment which can be added to 
+At present, there is no concept of a user role in the Context Mapper DSL; however, we used [Sculptor](https://sculptor.github.io/)'s `doc` comment which can be added to 
 all domain objects. Thereby we declare the user roles on our commands:
 
 ```text
@@ -272,7 +272,7 @@ The order in which we listed the events/commands above and the comments `// trig
 Once your CML that models the Event Storming output validates, you can:
 
 * Refine it, for instance by defining the data (attributes, operation parameters and return types) in more detail.
-    * Checkout the [tactic DDD syntax](/docs/tactic-ddd/) and the [Sculptor documentation](http://sculptorgenerator.org/documentation/advanced-tutorial).
+    * Checkout the [tactic DDD syntax](/docs/tactic-ddd/) and the [Sculptor documentation](https://sculptor.github.io/documentation/advanced-tutorial).
 * [Refactor it](/docs/architectural-refactorings/), starting with use cases and team assignments ([AR-2](/docs/ar-split-bounded-context-by-use-cases/), 
   [AR-3](/docs/ar-split-bounded-context-by-owners/), [etc.](/docs/architectural-refactorings/)).
 * [Generate output from it](/docs/generators/), for instance a [domain glossary](/docs/generic-freemarker-generator/), a [graphical Context Map](/docs/context-map-generator/), 
diff --git a/_news/2023-05-08-v6.8.0-released.md b/_news/2023-05-08-v6.8.0-released.md
@@ -26,7 +26,7 @@ If you use these asterisks, they are now used in the [PlantUML generator](/docs/
 <a href="/img/QuoteRequestFlow_BC_InsuranceQuotes_QuoteRequestFlow_StateDiagram_with-end-States.png">![PlantUML State Diagram](/img/QuoteRequestFlow_BC_InsuranceQuotes_QuoteRequestFlow_StateDiagram_with-end-States.png)</a>
 
 ### Tactic DDD: Lists of Enums
-Sometimes it can be useful to have collections of enum values. This was not supported by the original [Sculptor DSL](http://sculptorgenerator.org/) as we integrated it. We adjusted the DSL now so that collections of enums are supported. The following example illustrates a use case:
+Sometimes it can be useful to have collections of enum values. This was not supported by the original [Sculptor DSL](https://sculptor.github.io/) as we integrated it. We adjusted the DSL now so that collections of enums are supported. The following example illustrates a use case:
 
 ![List of Enums](/img/list-of-enums-sample.png)
 
