From 91f6df8b304ab7ec51574cbdec4fbdce9a61a9a6 Mon Sep 17 00:00:00 2001 From: Florian Kraemer Date: Mon, 23 Oct 2023 23:37:56 +0200 Subject: [PATCH 1/8] Adding SCOS example module page --- docs/scos/dev/example-modules.md | 66 ++++++++++++++++++++++++++++++++ shell/run.sh | 13 +++++++ 2 files changed, 79 insertions(+) create mode 100644 docs/scos/dev/example-modules.md create mode 100755 shell/run.sh diff --git a/docs/scos/dev/example-modules.md b/docs/scos/dev/example-modules.md new file mode 100644 index 00000000000..22f796b23ea --- /dev/null +++ b/docs/scos/dev/example-modules.md @@ -0,0 +1,66 @@ + +## The difference between core and example modules + +**Core modules** provide generic, reusable functionality that benefits a wide range of projects. They offer a foundation for customization and serve as versatile building blocks. + +**Example Modules** in contrast, are designed for specific, one-off use-cases. Their functionality is tightly aligned with unique business requirements and isn't suitable for broad reuse. These modules serve as specialized, project-specific solutions. + +## Example module use-cases + +### SCOS: Showcase functionality + +SCOS uses example modules to fill the gap with concrete/example implementation over an abstract workflow (latter is the target of delivery), where the concrete/example implementation is never actually usable by any concrete customer or business use-case, thus the actual business logic is not part of the core (eg: Example picking strategy). + +### SCOS: Unique business use-case + +SCOS uses example modules to implement functionality that is unique business (customer) use-case specific. The actual business logic is not part of the core as it does NOT offer regular core quality and is extracted into an example module. + +## Obligations + +### Exclusions and Non-Commitments + +Sprkyer has no strict obligations regarding the maintenance, compatibility, flexibility, and extendibility of the example modules. + +* **Compliance** + * Example modules MUST NOT be mapped to features. + * Examples modules MUST never reach a stable release. +* **Compatibility** + * Forward and backward compatibility is NOT in scope (more majors). + * NO upgradability support for projects, or demoshop integrations. +* **Learnability** + * NO commitment on documentation (MAY increase learning curve for project / core development). +* **Maintainability** + * There is NO obligation to maintain them. + * They MAY be abandoned at any time. + * They are NOT supported in any way. + * Maintenance is NOT part of the design (more expensive core adjustments & more majors around core adjustments). +* **Customisability** + * They do NOT support to build other functionality on/related to them (neither for core/project). + * Consequence: Application infrastructure can NOT be developed in example module. + * They are NOT designed to be used, extended, configured on project production. +* **Modularity** + * NO guarantee on modularity & reusability (the parts are NOT designed to be reusable without investment both for project/core). +* **Security** + * NO obligations on security fixes. +* **Performance** + * NO commitment on performance. +* **Testability** + * (NOT wired in Spryker Products) NO commitment on any level of correct behaviour per any release. + +### Commitments + +* **Compliance** + * The code quality MUST match the project quality guidelines (or better). + * New Example Modules MUST be in the “example organisation” (SprykerExample). + * All Example Modules MUST be released as standalone modules. + * All Example Modules MUST be released under the MIT license. +* **Maintenance** + * Feature integrations in Spryker Products MUST be aligned with the integrated example modules (extra maintenance effort on the Feature modules + on the example module). + * Project development MUST clean-up (aka “remove”) the example module when enabling it for production. +* **Uniformity** + * Example modules MUST be suffixed with “example”. + * Example modules MUST provide the before-mentioned disclaimer. +* **Testability** + * They SHOULD provide tests. +* **Learnability** + * A proper explanation of the implemented functionality MUST be provided in the `readme.md`. diff --git a/shell/run.sh b/shell/run.sh new file mode 100755 index 00000000000..345fb2d7eba --- /dev/null +++ b/shell/run.sh @@ -0,0 +1,13 @@ +#!/bin/bash + +# Define source and target paths +source_path="$PWD" +bundle_path="$source_path/vendor/bundle" + +# Run Jekyll with options +docker run --rm \ + --volume="$source_path:/srv/jekyll" \ + --volume="$bundle_path:/usr/local/bundle" \ + -p 4000:4000 \ + jekyll/jekyll:4.2.0 jekyll serve \ + --incremental --livereload From e06e6d53f6e65247bc9e885ea183e11d22292406 Mon Sep 17 00:00:00 2001 From: Florian Kraemer Date: Tue, 24 Oct 2023 14:01:33 +0200 Subject: [PATCH 2/8] Refining the example modules page --- docs/scos/dev/example-modules.md | 39 +++++++++++++------------------- 1 file changed, 16 insertions(+), 23 deletions(-) diff --git a/docs/scos/dev/example-modules.md b/docs/scos/dev/example-modules.md index 22f796b23ea..a5fa2b10c8e 100644 --- a/docs/scos/dev/example-modules.md +++ b/docs/scos/dev/example-modules.md @@ -1,7 +1,7 @@ ## The difference between core and example modules -**Core modules** provide generic, reusable functionality that benefits a wide range of projects. They offer a foundation for customization and serve as versatile building blocks. +**Core modules** provide generic, reusable functionality that benefits a wide range of customers. They offer a foundation for customization and serve as versatile building blocks. **Example Modules** in contrast, are designed for specific, one-off use-cases. Their functionality is tightly aligned with unique business requirements and isn't suitable for broad reuse. These modules serve as specialized, project-specific solutions. @@ -9,7 +9,7 @@ ### SCOS: Showcase functionality -SCOS uses example modules to fill the gap with concrete/example implementation over an abstract workflow (latter is the target of delivery), where the concrete/example implementation is never actually usable by any concrete customer or business use-case, thus the actual business logic is not part of the core (eg: Example picking strategy). +SCOS uses example modules to fill the gap with concrete/example implementation over an abstract workflow (latter is the target of delivery), where the concrete/example implementation is never actually usable by any concrete customer or business use-case, thus the actual business logic is not part of the core (eg: the React API Example). ### SCOS: Unique business use-case @@ -22,45 +22,38 @@ SCOS uses example modules to implement functionality that is unique business (cu Sprkyer has no strict obligations regarding the maintenance, compatibility, flexibility, and extendibility of the example modules. * **Compliance** - * Example modules MUST NOT be mapped to features. - * Examples modules MUST never reach a stable release. + * Examples modules will never reach a stable release. * **Compatibility** - * Forward and backward compatibility is NOT in scope (more majors). + * Forward and backward compatibility is NOT guranteed. * NO upgradability support for projects, or demoshop integrations. * **Learnability** - * NO commitment on documentation (MAY increase learning curve for project / core development). + * NO commitment on documentation. * **Maintainability** * There is NO obligation to maintain them. * They MAY be abandoned at any time. * They are NOT supported in any way. - * Maintenance is NOT part of the design (more expensive core adjustments & more majors around core adjustments). + * Maintenance is NOT part of the design. * **Customisability** - * They do NOT support to build other functionality on/related to them (neither for core/project). - * Consequence: Application infrastructure can NOT be developed in example module. - * They are NOT designed to be used, extended, configured on project production. + * They do NOT support to build other functionality on/related to them. + * They are NOT designed to be used, extended, configured in projects. * **Modularity** - * NO guarantee on modularity & reusability (the parts are NOT designed to be reusable without investment both for project/core). + * NO guarantee on modularity & reusability. * **Security** * NO obligations on security fixes. * **Performance** * NO commitment on performance. * **Testability** - * (NOT wired in Spryker Products) NO commitment on any level of correct behaviour per any release. + * NO commitment on any level of correct behaviour per any release. ### Commitments * **Compliance** - * The code quality MUST match the project quality guidelines (or better). - * New Example Modules MUST be in the “example organisation” (SprykerExample). - * All Example Modules MUST be released as standalone modules. - * All Example Modules MUST be released under the MIT license. -* **Maintenance** - * Feature integrations in Spryker Products MUST be aligned with the integrated example modules (extra maintenance effort on the Feature modules + on the example module). - * Project development MUST clean-up (aka “remove”) the example module when enabling it for production. + * All Example Modules will be part of the Spyker Example organization on Github. + * All Example Modules will be released as standalone modules. + * All Example Modules will be released under the MIT license. * **Uniformity** - * Example modules MUST be suffixed with “example”. - * Example modules MUST provide the before-mentioned disclaimer. + * Example modules will be suffixed with “example”. * **Testability** - * They SHOULD provide tests. + * They might provide tests. * **Learnability** - * A proper explanation of the implemented functionality MUST be provided in the `readme.md`. + * A proper explanation of the implemented functionality will be provided in the `readme.md`. From 7f0b64c8cb8baed260fb2f4b2bd97081c9bb36d4 Mon Sep 17 00:00:00 2001 From: Florian Kraemer Date: Wed, 1 Nov 2023 16:07:19 +0100 Subject: [PATCH 3/8] Updating the example modules page. --- docs/scos/dev/example-modules.md | 52 ++++++++++++++++---------------- 1 file changed, 26 insertions(+), 26 deletions(-) diff --git a/docs/scos/dev/example-modules.md b/docs/scos/dev/example-modules.md index a5fa2b10c8e..9c6da72bd92 100644 --- a/docs/scos/dev/example-modules.md +++ b/docs/scos/dev/example-modules.md @@ -15,45 +15,45 @@ SCOS uses example modules to fill the gap with concrete/example implementation o SCOS uses example modules to implement functionality that is unique business (customer) use-case specific. The actual business logic is not part of the core as it does NOT offer regular core quality and is extracted into an example module. -## Obligations +## What Spryker delivers -### Exclusions and Non-Commitments +* **Compliance** + * All Example Modules will be part of the Spyker Example organization on Github. + * All Example Modules will be released as standalone modules. + * All Example Modules will be released under the MIT license. +* **Uniformity** + * Example modules will be suffixed with “example”. +* **Testability** + * They might provide tests, but they don't have to. +* **Learnability** + * A proper explanation of the implemented functionality will be provided in the `readme.md`. -Sprkyer has no strict obligations regarding the maintenance, compatibility, flexibility, and extendibility of the example modules. +## What's Not Included -* **Compliance** - * Examples modules will never reach a stable release. +Unlinke for our SCOS Core Modules, Sprkyer has no strict guidelines and regulations regarding the Example Modules. + +* **Stability** + * We aim to keep our example modules in good shape, but we don't promise a stable release. * **Compatibility** - * Forward and backward compatibility is NOT guranteed. - * NO upgradability support for projects, or demoshop integrations. + * While we work to keep things compatible, we can't guarantee forward or backward compatibility. + * There is no upgradability support for projects, or demoshop integrations. * **Learnability** - * NO commitment on documentation. + * We provide documentation when we can, but it's not a firm commitment. We encourage community learning and support. * **Maintainability** * There is NO obligation to maintain them. * They MAY be abandoned at any time. * They are NOT supported in any way. * Maintenance is NOT part of the design. * **Customisability** - * They do NOT support to build other functionality on/related to them. - * They are NOT designed to be used, extended, configured in projects. + * We don't support nor encourage customization of example modules. + * They are never designed to be used, extended or configured in projects. * **Modularity** - * NO guarantee on modularity & reusability. + * No additional effort regarding modularity and extendibility will be made for example modules. * **Security** - * NO obligations on security fixes. + * Sprkyer provides security for it's production grade core modules. Example modules might receive security updates but there is no urgency for security fixes for example modules, as they are not intended to be used in production. * **Performance** - * NO commitment on performance. + * While we try to deliver good performance, we have no intention to optimize example modules beyond any best practice we already apply. * **Testability** - * NO commitment on any level of correct behaviour per any release. + * We might provide tests for the example modules but they have no priority, because the modules are not thought to be used in production or to be extended. -### Commitments - -* **Compliance** - * All Example Modules will be part of the Spyker Example organization on Github. - * All Example Modules will be released as standalone modules. - * All Example Modules will be released under the MIT license. -* **Uniformity** - * Example modules will be suffixed with “example”. -* **Testability** - * They might provide tests. -* **Learnability** - * A proper explanation of the implemented functionality will be provided in the `readme.md`. +In a nutshell, think of our example packages as a playground - there's potential for fun and innovations -, explore at your own pace! \ No newline at end of file From 8bd7dc04fcd80ee3ea4ae1ab7b9cba1498eb147e Mon Sep 17 00:00:00 2001 From: Helen Kravchenko Date: Thu, 11 Jan 2024 12:12:06 +0100 Subject: [PATCH 4/8] Update example-modules.md --- docs/scos/dev/example-modules.md | 100 ++++++++++++++++--------------- 1 file changed, 53 insertions(+), 47 deletions(-) diff --git a/docs/scos/dev/example-modules.md b/docs/scos/dev/example-modules.md index 9c6da72bd92..b4fe87467eb 100644 --- a/docs/scos/dev/example-modules.md +++ b/docs/scos/dev/example-modules.md @@ -1,59 +1,65 @@ +--- +title: Example modules +description: Spryker example modules are designed for specific use cases and their functionality is aligned with unique business requirements. +last_updated: Jan 11, 2024 +template: concept-topic-template +--- -## The difference between core and example modules +The Spryker *core modules* provide generic, reusable functionality that benefits a wide range of use cases. These modules offer a foundation for customization and serve as versatile building blocks. -**Core modules** provide generic, reusable functionality that benefits a wide range of customers. They offer a foundation for customization and serve as versatile building blocks. - -**Example Modules** in contrast, are designed for specific, one-off use-cases. Their functionality is tightly aligned with unique business requirements and isn't suitable for broad reuse. These modules serve as specialized, project-specific solutions. +*Example modules* in contrast, are designed for specific, one-off use-cases. Their functionality is tightly aligned with unique business requirements and isn't suitable for broad reuse. These modules serve as specialized, project-specific solutions. ## Example module use-cases -### SCOS: Showcase functionality +Use-cases for example modules include showcasing functionality and demonstrating specific use cases. + +### SCCOS: Showcase functionality -SCOS uses example modules to fill the gap with concrete/example implementation over an abstract workflow (latter is the target of delivery), where the concrete/example implementation is never actually usable by any concrete customer or business use-case, thus the actual business logic is not part of the core (eg: the React API Example). +SCCOS uses example modules to fill the gap with concrete example implementation for an abstract workflow, which is the delivery target. However, this concrete implementation is not intended for actual use by any specific customer or business use-case. Therefore, the core does not include the actual business logic, such as the React API example. -### SCOS: Unique business use-case +### SCCOS: Unique business use-case -SCOS uses example modules to implement functionality that is unique business (customer) use-case specific. The actual business logic is not part of the core as it does NOT offer regular core quality and is extracted into an example module. +SCCOS uses example modules to implement functionality that is tailored to specific business use cases. The core does not include the actual business logic, as it doesn't meet the standard core quality. Instead, this logic is extracted into an example module. ## What Spryker delivers -* **Compliance** - * All Example Modules will be part of the Spyker Example organization on Github. - * All Example Modules will be released as standalone modules. - * All Example Modules will be released under the MIT license. -* **Uniformity** +* **Compliance:** + * All example modules will be part of the Spyker Example organization on Github. + * All example modules will be released as standalone modules. + * All example modules will be released under the MIT license. +* **Uniformity:** * Example modules will be suffixed with “example”. -* **Testability** - * They might provide tests, but they don't have to. -* **Learnability** - * A proper explanation of the implemented functionality will be provided in the `readme.md`. - -## What's Not Included - -Unlinke for our SCOS Core Modules, Sprkyer has no strict guidelines and regulations regarding the Example Modules. - -* **Stability** - * We aim to keep our example modules in good shape, but we don't promise a stable release. -* **Compatibility** - * While we work to keep things compatible, we can't guarantee forward or backward compatibility. - * There is no upgradability support for projects, or demoshop integrations. -* **Learnability** - * We provide documentation when we can, but it's not a firm commitment. We encourage community learning and support. -* **Maintainability** - * There is NO obligation to maintain them. - * They MAY be abandoned at any time. - * They are NOT supported in any way. - * Maintenance is NOT part of the design. -* **Customisability** - * We don't support nor encourage customization of example modules. - * They are never designed to be used, extended or configured in projects. -* **Modularity** - * No additional effort regarding modularity and extendibility will be made for example modules. -* **Security** - * Sprkyer provides security for it's production grade core modules. Example modules might receive security updates but there is no urgency for security fixes for example modules, as they are not intended to be used in production. -* **Performance** - * While we try to deliver good performance, we have no intention to optimize example modules beyond any best practice we already apply. -* **Testability** - * We might provide tests for the example modules but they have no priority, because the modules are not thought to be used in production or to be extended. - -In a nutshell, think of our example packages as a playground - there's potential for fun and innovations -, explore at your own pace! \ No newline at end of file +* **Testability:** + * Example modules might include tests, but they don't have to. +* **Learnability:** + * A proper explanation of the implemented functionality will be provided in the `readme.md` file. + +## What isn't included + +In contrast to Spryker SCCOS core modules, example modules do not adhere to strict guidelines and regulations. + +* **Stability:** + While we strive to maintain the quality of our example modules, we do not guarantee a stable release. +* **Compatibility:** + * While we do our best to keep things compatible, we can't guarantee forward or backward compatibility. + * There is no upgradability support for projects or Demo Shop integrations. +* **Learnability:** + While documentation is provided when possible, it is not a firm commitment. We encourage community learning and support. +* **Maintainability:** + * There is no obligation to maintain example modules. + * Example modules may be abandoned at any time. + * Example modules aren't supported in any way. + * Maintenance isn't part of the design. +* **Customizability:** + * We neither support nor encourage customization of example modules. + * Example modules have not been designed for use, extension, or configuration in projects. +* **Modularity:** + No additional effort will be invested in enhancing modularity and extendibility for example modules. +* **Security:** + Spryker ensures security for its production-grade core modules. While example modules might receive security updates, there is no urgency for fixes, as they are not intended for production use. +* **Performance:** + * While we aim for good performance, optimizing example modules beyond existing best practices is not a priority. +* **Testability:** + * We might provide tests for example modules but they don't have high priority, as the modules aren't intended for production use or extension. + +In a nutshell, think of our example packages as a playground - they offer potential for fun and innovation, so explore them at your own pace. \ No newline at end of file From 9f8a7776b1f003977347fb235503d8e217fcb96b Mon Sep 17 00:00:00 2001 From: Helen Kravchenko Date: Thu, 11 Jan 2024 12:12:12 +0100 Subject: [PATCH 5/8] Update scos_dev_sidebar.yml --- _data/sidebars/scos_dev_sidebar.yml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/_data/sidebars/scos_dev_sidebar.yml b/_data/sidebars/scos_dev_sidebar.yml index 9c4faf77130..2841e5842a3 100644 --- a/_data/sidebars/scos_dev_sidebar.yml +++ b/_data/sidebars/scos_dev_sidebar.yml @@ -3163,6 +3163,8 @@ entries: url: /docs/scos/dev/updating-spryker/switch-demo-shop-version.html - title: Troubleshooting updates url: /docs/scos/dev/updating-spryker/troubleshooting-updates.html + - title: Example modules + url: /docs/scos/dev/example-modules.html - title: Code contribution guide url: /docs/scos/dev/code-contribution-guide.html ... From 7d586ed169aeae6295d074ab85324065c8fdc21e Mon Sep 17 00:00:00 2001 From: Helen Kravchenko Date: Thu, 11 Jan 2024 12:14:30 +0100 Subject: [PATCH 6/8] Update example-modules.md --- docs/scos/dev/example-modules.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/docs/scos/dev/example-modules.md b/docs/scos/dev/example-modules.md index b4fe87467eb..f4a92958271 100644 --- a/docs/scos/dev/example-modules.md +++ b/docs/scos/dev/example-modules.md @@ -15,7 +15,7 @@ Use-cases for example modules include showcasing functionality and demonstrating ### SCCOS: Showcase functionality -SCCOS uses example modules to fill the gap with concrete example implementation for an abstract workflow, which is the delivery target. However, this concrete implementation is not intended for actual use by any specific customer or business use-case. Therefore, the core does not include the actual business logic, such as the React API example. +SCCOS uses example modules to fill the gap with concrete example implementation for an abstract workflow, which is the delivery target. However, this concrete implementation is not intended for actual use by any specific customer or business use-case. Therefore, the core does not include the actual business logic. ### SCCOS: Unique business use-case @@ -58,8 +58,8 @@ In contrast to Spryker SCCOS core modules, example modules do not adhere to stri * **Security:** Spryker ensures security for its production-grade core modules. While example modules might receive security updates, there is no urgency for fixes, as they are not intended for production use. * **Performance:** - * While we aim for good performance, optimizing example modules beyond existing best practices is not a priority. + While we aim for good performance, optimizing example modules beyond existing best practices is not a priority. * **Testability:** - * We might provide tests for example modules but they don't have high priority, as the modules aren't intended for production use or extension. + We might provide tests for example modules but they don't have high priority, as the modules aren't intended for production use or extension. -In a nutshell, think of our example packages as a playground - they offer potential for fun and innovation, so explore them at your own pace. \ No newline at end of file +In a nutshell, think of our example packages as a playground - they offer potential for fun and innovation, so explore them at your own pace. From f360d252928e8c4340cbea721e75157f567b48d9 Mon Sep 17 00:00:00 2001 From: Florian Kraemer Date: Thu, 11 Jan 2024 13:53:14 +0100 Subject: [PATCH 7/8] Adding an example module link --- docs/scos/dev/example-modules.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/scos/dev/example-modules.md b/docs/scos/dev/example-modules.md index f4a92958271..84d32f91628 100644 --- a/docs/scos/dev/example-modules.md +++ b/docs/scos/dev/example-modules.md @@ -7,7 +7,7 @@ template: concept-topic-template The Spryker *core modules* provide generic, reusable functionality that benefits a wide range of use cases. These modules offer a foundation for customization and serve as versatile building blocks. -*Example modules* in contrast, are designed for specific, one-off use-cases. Their functionality is tightly aligned with unique business requirements and isn't suitable for broad reuse. These modules serve as specialized, project-specific solutions. +*Example modules* in contrast, are designed for specific, one-off use-cases. Their functionality is tightly aligned with unique business requirements and isn't suitable for broad reuse. These modules serve as specialized, project-specific solutions. See the [Product Warehouse Allocation Example](https://github.com/spryker/product-warehouse-allocation-example) module. ## Example module use-cases From a8429db2ffb811f1caa25bc45abe6756c3f8b882 Mon Sep 17 00:00:00 2001 From: Helen Kravchenko Date: Fri, 12 Jan 2024 12:01:26 +0100 Subject: [PATCH 8/8] typos fixes --- docs/scos/dev/example-modules.md | 10 +++++----- shell/run.sh | 13 ------------- 2 files changed, 5 insertions(+), 18 deletions(-) delete mode 100755 shell/run.sh diff --git a/docs/scos/dev/example-modules.md b/docs/scos/dev/example-modules.md index 84d32f91628..70f9a34653c 100644 --- a/docs/scos/dev/example-modules.md +++ b/docs/scos/dev/example-modules.md @@ -7,15 +7,15 @@ template: concept-topic-template The Spryker *core modules* provide generic, reusable functionality that benefits a wide range of use cases. These modules offer a foundation for customization and serve as versatile building blocks. -*Example modules* in contrast, are designed for specific, one-off use-cases. Their functionality is tightly aligned with unique business requirements and isn't suitable for broad reuse. These modules serve as specialized, project-specific solutions. See the [Product Warehouse Allocation Example](https://github.com/spryker/product-warehouse-allocation-example) module. +*Example modules*, in contrast, are designed for specific, one-off use cases. Their functionality is tightly aligned with unique business requirements and isn't suitable for broad reuse. These modules serve as specialized, project-specific solutions. See the [Product Warehouse Allocation Example](https://github.com/spryker/product-warehouse-allocation-example) module. ## Example module use-cases -Use-cases for example modules include showcasing functionality and demonstrating specific use cases. +Use cases for example modules include showcasing functionality and demonstrating specific use cases. ### SCCOS: Showcase functionality -SCCOS uses example modules to fill the gap with concrete example implementation for an abstract workflow, which is the delivery target. However, this concrete implementation is not intended for actual use by any specific customer or business use-case. Therefore, the core does not include the actual business logic. +SCCOS uses example modules to fill the gap with concrete example implementation for an abstract workflow, which is the delivery target. However, this concrete implementation is not intended for actual use by any specific customer or business use case. Therefore, the core does not include the actual business logic. ### SCCOS: Unique business use-case @@ -24,7 +24,7 @@ SCCOS uses example modules to implement functionality that is tailored to specif ## What Spryker delivers * **Compliance:** - * All example modules will be part of the Spyker Example organization on Github. + * All example modules will be part of the Spyker Example organization on GitHub. * All example modules will be released as standalone modules. * All example modules will be released under the MIT license. * **Uniformity:** @@ -60,6 +60,6 @@ In contrast to Spryker SCCOS core modules, example modules do not adhere to stri * **Performance:** While we aim for good performance, optimizing example modules beyond existing best practices is not a priority. * **Testability:** - We might provide tests for example modules but they don't have high priority, as the modules aren't intended for production use or extension. + We might provide tests for example modules, but they don't have high priority, as the modules aren't intended for production use or extension. In a nutshell, think of our example packages as a playground - they offer potential for fun and innovation, so explore them at your own pace. diff --git a/shell/run.sh b/shell/run.sh deleted file mode 100755 index 345fb2d7eba..00000000000 --- a/shell/run.sh +++ /dev/null @@ -1,13 +0,0 @@ -#!/bin/bash - -# Define source and target paths -source_path="$PWD" -bundle_path="$source_path/vendor/bundle" - -# Run Jekyll with options -docker run --rm \ - --volume="$source_path:/srv/jekyll" \ - --volume="$bundle_path:/usr/local/bundle" \ - -p 4000:4000 \ - jekyll/jekyll:4.2.0 jekyll serve \ - --incremental --livereload