Merge branch 'antora-debug'

anoff · Feb 8, 2019 · 61a8fd3 · 61a8fd3
2 parents 33b424c + 84479c2
commit 61a8fd3
Show file tree

Hide file tree

Showing 16 changed files with 42 additions and 147 deletions.
diff --git a/.travis.yml b/.travis.yml
@@ -2,22 +2,12 @@ language: node_js
 node_js:
   - "10"
 
-script: make build
+script: npm run dist
 
 deploy:
   provider: pages
   skip-cleanup: true
   github-token: $GITHUB_TOKEN  # Set in the settings page of your repository, as a secure variable
   local-dir: ./dist/
   on:
-    branch: master
-
-# disable the default submodule logic
-#   https://gist.github.com/iedemam/9830045
-git:
-  submodules: false
-
-# use sed to replace the SSH URL with the public URL, then init and update submodules
-before_install:
-  - sed -i 's/git@github.com:/git:\/\/github.com\//' .gitmodules
-  - git submodule update --init --recursive
+    branch: [master]
diff --git a/docs/modules/ROOT/pages/01_introduction_and_goals.adoc b/docs/modules/ROOT/pages/01_introduction_and_goals.adoc
@@ -1,7 +1,6 @@
-[[section-introduction-and-goals]]
+:page-partial:
 == Introduction and Goals
 
-[role="arc42help"]
 ****
 Describes the relevant requirements and the driving forces that software architects and development team must consider. These include
 
@@ -12,7 +11,6 @@ Describes the relevant requirements and the driving forces that software archite
 
 === Requirements Overview
 
-[role="arc42help"]
 ****
 .Contents
 Short description of the functional requirements, driving forces, extract (or abstract)
@@ -32,7 +30,6 @@ Keep these excerpts as short as possible. Balance readability of this document w
 
 === Quality Goals
 
-[role="arc42help"]
 ****
 .Contents
 The top three (max five) quality goals for the architecture whose fulfillment is of highest importance to the major stakeholders. We really mean quality goals for the architecture. Don't confuse them with project goals. They are not necessarily identical.
@@ -47,7 +44,6 @@ A table with quality goals and concrete scenarios, ordered by priorities
 
 === Stakeholders
 
-[role="arc42help"]
 ****
 .Contents
 Explicit overview of stakeholders of the system, i.e. all person, roles or organizations that

diff --git a/docs/modules/ROOT/pages/02_architecture_constraints.adoc b/docs/modules/ROOT/pages/02_architecture_constraints.adoc
@@ -1,8 +1,6 @@
-[[section-architecture-constraints]]
+:page-partial:
 == Architecture Constraints
 
-
-[role="arc42help"]
 ****
 .Contents
 Any requirement that constrains software architects in their freedom of design and implementation decisions or decision about the development process. These constraints sometimes go beyond individual systems and are valid for whole organizations and companies.

diff --git a/docs/modules/ROOT/pages/03_system_scope_and_context.adoc b/docs/modules/ROOT/pages/03_system_scope_and_context.adoc
@@ -1,8 +1,6 @@
-[[section-system-scope-and-context]]
+:page-partial:
 == System Scope and Context
 
-
-[role="arc42help"]
 ****
 .Contents
 System scope and context - as the name suggests - delimits your system (i.e. your scope) from all its communication partners
@@ -20,10 +18,8 @@ Various options:
 * Lists of communication partners and their interfaces.
 ****
 
-
 === Business Context
 
-[role="arc42help"]
 ****
 .Contents
 Specification of *all* communication partners (users, IT-systems, ...) with explanations of domain specific inputs and outputs or interfaces.
@@ -45,7 +41,6 @@ The title of the table is the name of your system, the three columns contain the
 
 === Technical Context
 
-[role="arc42help"]
 ****
 .Contents
 Technical interfaces (channels and transmission media) linking your system to its environment. In addition a mapping of domain specific input/output to the channels, i.e. an explanation with I/O uses which channel.

diff --git a/docs/modules/ROOT/pages/04_solution_strategy.adoc b/docs/modules/ROOT/pages/04_solution_strategy.adoc
@@ -1,8 +1,6 @@
-[[section-solution-strategy]]
+:page-partial:
 == Solution Strategy
 
-
-[role="arc42help"]
 ****
 .Contents
 A short summary and explanation of the fundamental decisions and solution strategies, that shape the system's architecture. These include

diff --git a/docs/modules/ROOT/pages/05_building_block_view.adoc b/docs/modules/ROOT/pages/05_building_block_view.adoc
@@ -1,9 +1,6 @@
-[[section-building-block-view]]
-
-
+:page-partial:
 == Building Block View
 
-[role="arc42help"]
 ****
 .Content
 The building block view shows the static decomposition of the system into building blocks (modules, components, subsystems, classes,
@@ -36,7 +33,6 @@ Thus it contains the white box description of selected building blocks of level
 
 === Whitebox Overall System
 
-[role="arc42help"]
 ****
 Here you describe the decomposition of the overall system using the following white box template. It contains
 
@@ -70,7 +66,6 @@ _<Description of contained building block (black boxes)>_
 Important Interfaces::
 _<Description of important interfaces>_
 
-[role="arc42help"]
 ****
 Insert your explanations of black boxes from level 1:
 
@@ -93,7 +88,6 @@ Its headline is the name of the black box.
 
 ==== <Name black box 1>
 
-[role="arc42help"]
 ****
 Here you describe <black box 1>
 according the the following black box template:
@@ -141,7 +135,6 @@ _<black box template>_
 
 === Level 2
 
-[role="arc42help"]
 ****
 Here you can specify the inner structure of (some) building blocks from level 1 as white boxes.
 
@@ -152,7 +145,6 @@ Leave out normal, simple, boring or standardized parts of your system
 
 ==== White Box _<building block 1>_
 
-[role="arc42help"]
 ****
 ...describes the internal structure of _building block 1_.
 ****
@@ -175,7 +167,6 @@ _<white box template>_
 
 === Level 3
 
-[role="arc42help"]
 ****
 Here you can specify the inner structure of (some) building blocks from level 2 as white boxes.
 
@@ -186,12 +177,10 @@ part of arc42 for additional levels.
 
 ==== White Box <_building block x.1_>
 
-[role="arc42help"]
 ****
 Specifies the internal structure of _building block x.1_.
 ****
 
-
 _<white box template>_
 
 
@@ -200,7 +189,6 @@ _<white box template>_
 _<white box template>_
 
 
-
 ==== White Box <_building block y.1_>
 
 _<white box template>_
diff --git a/docs/modules/ROOT/pages/06_runtime_view.adoc b/docs/modules/ROOT/pages/06_runtime_view.adoc
@@ -1,8 +1,6 @@
-[[section-runtime-view]]
+:page-partial:
 == Runtime View
 
-
-[role="arc42help"]
 ****
 .Contents
 The runtime view describes concrete behavior and interactions of the system’s building blocks in form of scenarios from the following areas:

diff --git a/docs/modules/ROOT/pages/07_deployment_view.adoc b/docs/modules/ROOT/pages/07_deployment_view.adoc
@@ -1,42 +1,8 @@
-[[section-deployment-view]]
-
-
+:page-partial:
 == Deployment View
 
-[role="arc42help"]
-****
-.Content
-The deployment view describes:
-
- 1. the technical infrastructure used to execute your system, with infrastructure elements like geographical locations, environments, computers, processors, channels and net topologies as well as other infrastructure elements and
-
-2. the mapping of (software) building blocks to that infrastructure elements.
-
-Often systems are executed in different environments, e.g. development environment, test environment, production environment. In such cases you should document all relevant environments.
-
-Especially document the deployment view when your software is executed as distributed system with more then one computer, processor, server or container or when you design and construct your own hardware processors and chips.
-
-From a software perspective it is sufficient to capture those elements of the infrastructure that are needed to show the deployment of your building blocks. Hardware architects can go beyond that and describe the infrastructure to any level of detail they need to capture.
-
-.Motivation
-Software does not run without hardware.
-This underlying infrastructure can and will influence your system and/or some
-cross-cutting concepts. Therefore, you need to know the infrastructure.
-
-.Form
-
-Maybe the highest level deployment diagram is already contained in section 3.2. as
-technical context with your own infrastructure as ONE black box. In this section you will
-zoom into this black box using additional deployment diagrams:
-
-* UML offers deployment diagrams to express that view. Use it, probably with nested diagrams,
-when your infrastructure is more complex.
-* When your (hardware) stakeholders prefer other kinds of diagrams rather than the deployment diagram, let them use any kind that is able to show nodes and channels of the infrastructure.
-****
-
 === Infrastructure Level 1
 
-[role="arc42help"]
 ****
 Describe (usually in a combination of diagrams, tables, and text):
 
@@ -64,7 +30,6 @@ _<description of the mapping>_
 
 === Infrastructure Level 2
 
-[role="arc42help"]
 ****
 Here you can include the internal structure of (some) infrastructure elements from level 1.
 

diff --git a/docs/modules/ROOT/pages/08_concepts.adoc b/docs/modules/ROOT/pages/08_concepts.adoc
@@ -1,8 +1,6 @@
-[[section-concepts]]
+:page-partial:
 == Cross-cutting Concepts
 
-
-[role="arc42help"]
 ****
 .Content
 This section describes overall, principal regulations and solution ideas that are

diff --git a/docs/modules/ROOT/pages/09_design_decisions.adoc b/docs/modules/ROOT/pages/09_design_decisions.adoc
@@ -1,8 +1,6 @@
-[[section-design-decisions]]
+:page-partial:
 == Design Decisions
 
-
-[role="arc42help"]
 ****
 .Contents
 Important, expensive, large scale or risky architecture decisions including rationals.

diff --git a/docs/modules/ROOT/pages/10_quality_scenarios.adoc b/docs/modules/ROOT/pages/10_quality_scenarios.adoc
@@ -1,8 +1,6 @@
-[[section-quality-scenarios]]
+:page-partial:
 == Quality Requirements
 
-
-[role="arc42help"]
 ****
 
 .Content
@@ -19,7 +17,6 @@ concrete and measurable.
 
 === Quality Tree
 
-[role="arc42help"]
 ****
 .Content
 The quality tree (as defined in ATAM – Architecture Tradeoff Analysis Method) with quality/evaluation scenarios as leafs.
@@ -38,7 +35,6 @@ In any case the tree should include links to the scenarios of the following sect
 
 === Quality Scenarios
 
-[role="arc42help"]
 ****
 .Contents
 Concretization of (sometimes vague or implicit) quality requirements using (quality) scenarios.

diff --git a/docs/modules/ROOT/pages/11_technical_risks.adoc b/docs/modules/ROOT/pages/11_technical_risks.adoc
@@ -1,8 +1,6 @@
-[[section-technical-risks]]
+:page-partial:
 == Risks and Technical Debts
 
-
-[role="arc42help"]
 ****
 .Contents
 A list of identified technical risks or technical debts, ordered by priority

diff --git a/docs/modules/ROOT/pages/12_glossary.adoc b/docs/modules/ROOT/pages/12_glossary.adoc
@@ -1,9 +1,6 @@
-[[section-glossary]]
+:page-partial:
 == Glossary
 
-
-
-[role="arc42help"]
 ****
 .Contents
 The most important domain and technical terms that your stakeholders use when discussing the system.