diff --git a/aadarchi-maven-plugin/pom.xml b/aadarchi-maven-plugin/pom.xml
index 20e3f635..f8cfb6c6 100644
--- a/aadarchi-maven-plugin/pom.xml
+++ b/aadarchi-maven-plugin/pom.xml
@@ -12,6 +12,12 @@
Agile Architecture Documentation System : Maven plugin
+
+
+ org.twdata.maven
+ mojo-executor
+ 2.4.0
+
javax.enterprise
cdi-api
diff --git a/aadarchi-maven-plugin/src/it/from_workspace_dsl/pom.xml b/aadarchi-maven-plugin/src/it/1_from_workspace_dsl/pom.xml
similarity index 100%
rename from aadarchi-maven-plugin/src/it/from_workspace_dsl/pom.xml
rename to aadarchi-maven-plugin/src/it/1_from_workspace_dsl/pom.xml
diff --git a/aadarchi-maven-plugin/src/it/from_workspace_dsl/src/architecture/resources/workspace.dsl b/aadarchi-maven-plugin/src/it/1_from_workspace_dsl/src/architecture/resources/workspace.dsl
similarity index 100%
rename from aadarchi-maven-plugin/src/it/from_workspace_dsl/src/architecture/resources/workspace.dsl
rename to aadarchi-maven-plugin/src/it/1_from_workspace_dsl/src/architecture/resources/workspace.dsl
diff --git a/aadarchi-maven-plugin/src/it/from_workspace_dsl/verify.groovy b/aadarchi-maven-plugin/src/it/1_from_workspace_dsl/verify.groovy
similarity index 100%
rename from aadarchi-maven-plugin/src/it/from_workspace_dsl/verify.groovy
rename to aadarchi-maven-plugin/src/it/1_from_workspace_dsl/verify.groovy
diff --git a/aadarchi-maven-plugin/src/it/2_generate_html_docs/pom.xml b/aadarchi-maven-plugin/src/it/2_generate_html_docs/pom.xml
new file mode 100644
index 00000000..8b93f18a
--- /dev/null
+++ b/aadarchi-maven-plugin/src/it/2_generate_html_docs/pom.xml
@@ -0,0 +1,132 @@
+
+
+ io.github.Riduidel.agile-architecture-documentation-system
+ 0.0.12-SNAPSHOT
+ 4.0.0
+
+ simple
+ Agile Architecture Documentation System : System documentation generator
+ Using agile architecture documentation system to document agile archiecture documentation system
+
+ https://kroki.io
+ 11
+ UTF-8
+ UTF-8
+ highlightjs
+ src/docs/asciidoc
+ src/slides/asciidoc
+ ${project.build.directory}/asciidoc
+ ${asciidoc.target.base.directory}/docs
+ ${asciidoc.target.base.directory}/slides
+ org.ndx.agile.architecture.base.ArchitectureDocumentationBuilder
+ ${project.build.directory}/structurizr
+ ${agile.architecture.output.dir}/diagrams
+ ${agile.architecture.output.dir}/enhancements
+
+
+
+ https://github.com/Riduidel/agile-architecture-documentation-system/issues
+
+
+
+ 2.1.0
+
+ 1.5.4
+
+ 2.4.3
+
+ 4.1.0
+
+ 0.5.0
+
+ 9.2.9.0
+
+ 3.9.2
+
+
+
+ ${issues.url}
+
+
+
+
+
+ mavengems
+ mavengem:https://rubygems.org
+
+
+
+
+
+ rubygems
+ asciidoctor-kroki
+ ${version.asciidoctor.kroki}
+ gem
+
+
+
+ rubygems
+ asciidoctor
+
+
+ rubygems
+ thread_safe
+
+
+ rubygems
+ concurrent-ruby
+
+
+
+
+
+
+
+
+
+ org.torquebox.mojo
+ mavengem-wagon
+ 1.0.3
+
+
+
+
+ de.saumya.mojo
+ gem-maven-plugin
+ 2.0.1
+
+ ${version.jruby}
+ ${project.build.directory}/gems
+ ${project.build.directory}/gems
+
+
+
+
+ install-gems
+
+ initialize
+
+ initialize
+
+
+
+
+ @project.groupId@
+ aadarchi-maven-plugin
+ @project.version@
+
+
+
+ generate-model
+ generate-html-docs
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/aadarchi-maven-plugin/src/it/2_generate_html_docs/src/architecture/resources/workspace.dsl b/aadarchi-maven-plugin/src/it/2_generate_html_docs/src/architecture/resources/workspace.dsl
new file mode 100644
index 00000000..7351fc1c
--- /dev/null
+++ b/aadarchi-maven-plugin/src/it/2_generate_html_docs/src/architecture/resources/workspace.dsl
@@ -0,0 +1,109 @@
+workspace "agile-architecture-documentation-system" {
+
+ model {
+ Architect_1 = person "Architect" "The architect as team scribe is the writer of this kind of documentation."
+ Stakeholder_2 = person "Stakeholder" "All project stakeholders are readers of this kind of documentation."
+ Agile_architecture_documentation_3 = softwareSystem "Agile architecture documentation" {
+ base_10 = container "base" {
+ SCMReadmeReader_17 = component "SCMReadmeReader" {
+ }
+ maven_metadata_inferer_37 = component "maven-metadata-inferer" {
+ }
+ adr_tickets_extractor_31 = component "adr-tickets-extractor" {
+ }
+ GraphEmitter_16 = component "GraphEmitter" {
+ }
+ ArchitectureEnhancer_15 = component "ArchitectureEnhancer" {
+ }
+ github_scm_handler_25 = component "github-scm-handler" {
+ }
+ ImplicitIncludeManager_13 = component "ImplicitIncludeManager" {
+ }
+ cdi_config_extension_35 = component "cdi-config-extension" {
+ }
+ SCMLinkGenerator_11 = component "SCMLinkGenerator" {
+ }
+ gitlab_scm_handler_28 = component "gitlab-scm-handler" {
+ }
+ DocumentsCollector_12 = component "DocumentsCollector" {
+ }
+ ArchitectureDocumentationBuilder_14 = component "ArchitectureDocumentationBuilder" {
+ }
+ }
+ asciidoc_39 = container "asciidoc" {
+ }
+ maven_8 = container "maven" {
+ }
+ archetype_6 = container "archetype" {
+ }
+ }
+ ArchitectureEnhancer_15 -> ImplicitIncludeManager_13 "Generates includes for all enhancers" ""
+ Architect_1 -> maven_8 "Generates documentation" ""
+ ArchitectureEnhancer_15 -> DocumentsCollector_12 "Collects documents in source folder" ""
+ ArchitectureEnhancer_15 -> adr_tickets_extractor_31 "Produces ADR reporting" ""
+ SCMReadmeReader_17 -> github_scm_handler_25 "Get project readme" ""
+ Architect_1 -> archetype_6 "Bootstrap a valid project" ""
+ SCMReadmeReader_17 -> gitlab_scm_handler_28 "Get project readme" ""
+ ArchitectureEnhancer_15 -> GraphEmitter_16 "Generates diagrams in PlantUML format" ""
+ maven_8 -> ArchitectureDocumentationBuilder_14 "Invokes that Java executable during maven build" ""
+ adr_tickets_extractor_31 -> github_scm_handler_25 "Read tickets from GitHub if configured so" ""
+ ArchitectureEnhancer_15 -> SCMLinkGenerator_11 "Generates links to SCM sources" ""
+ ArchitectureDocumentationBuilder_14 -> ArchitectureEnhancer_15 "Adds information to initial architecture description" ""
+ maven_8 -> base_10 "Generates diagrams and asciidoc includes" ""
+ maven_8 -> asciidoc_39 "Generates documentation as usable text in HTML/PDF/..." ""
+ SCMLinkGenerator_11 -> gitlab_scm_handler_28 "Get project source link" ""
+ adr_tickets_extractor_31 -> gitlab_scm_handler_28 "Read tickets from Gitlab if configured so" ""
+ ArchitectureDocumentationBuilder_14 -> maven_metadata_inferer_37 "Infer most of element details from Maven infos" ""
+ ArchitectureEnhancer_15 -> SCMReadmeReader_17 "Includes elements readme when they exist" ""
+ SCMLinkGenerator_11 -> github_scm_handler_25 "Get project source link" ""
+ ArchitectureDocumentationBuilder_14 -> cdi_config_extension_35 "Eases out some CDI code" ""
+ Stakeholder_2 -> Agile_architecture_documentation_3 "Read" ""
+ Architect_1 -> Agile_architecture_documentation_3 "Writes" ""
+ SCMReadmeReader_17 -> github_scm_handler_25 "Get project readme" ""
+ SCMReadmeReader_17 -> gitlab_scm_handler_28 "Get project readme" ""
+ adr_tickets_extractor_31 -> gitlab_scm_handler_28 "Read tickets from Gitlab if configured so" ""
+ adr_tickets_extractor_31 -> github_scm_handler_25 "Read tickets from GitHub if configured so" ""
+ ArchitectureEnhancer_15 -> DocumentsCollector_12 "Collects documents in source folder" ""
+ ArchitectureEnhancer_15 -> SCMLinkGenerator_11 "Generates links to SCM sources" ""
+ ArchitectureEnhancer_15 -> SCMReadmeReader_17 "Includes elements readme when they exist" ""
+ ArchitectureEnhancer_15 -> ImplicitIncludeManager_13 "Generates includes for all enhancers" ""
+ ArchitectureEnhancer_15 -> GraphEmitter_16 "Generates diagrams in PlantUML format" ""
+ ArchitectureEnhancer_15 -> adr_tickets_extractor_31 "Produces ADR reporting" ""
+ SCMLinkGenerator_11 -> github_scm_handler_25 "Get project source link" ""
+ SCMLinkGenerator_11 -> gitlab_scm_handler_28 "Get project source link" ""
+ ArchitectureDocumentationBuilder_14 -> ArchitectureEnhancer_15 "Adds information to initial architecture description" ""
+ ArchitectureDocumentationBuilder_14 -> cdi_config_extension_35 "Eases out some CDI code" ""
+ ArchitectureDocumentationBuilder_14 -> maven_metadata_inferer_37 "Infer most of element details from Maven infos" ""
+ maven_8 -> ArchitectureDocumentationBuilder_14 "Invokes that Java executable during maven build" ""
+ maven_8 -> base_10 "Generates diagrams and asciidoc includes" ""
+ maven_8 -> asciidoc_39 "Generates documentation as usable text in HTML/PDF/..." ""
+ }
+ views {
+ styles {
+ element "Software System" {
+ background #1168bd
+ color #ffffff
+ }
+ element "Person" {
+ shape person
+ background #08427b
+ color #ffffff
+ }
+ }
+ systemContext Agile_architecture_documentation_3 "SystemContext" {
+ include *
+ autoLayout
+ }
+
+ container Agile_architecture_documentation_3 "SystemContainers" {
+ include *
+ autoLayout
+ }
+
+ component base_10 "baseComponents" {
+ include *
+ autoLayout
+ }
+ }
+
+}
\ No newline at end of file
diff --git a/aadarchi-maven-plugin/src/it/2_generate_html_docs/src/docs/asciidoc/01-context.adoc b/aadarchi-maven-plugin/src/it/2_generate_html_docs/src/docs/asciidoc/01-context.adoc
new file mode 100644
index 00000000..aab831ee
--- /dev/null
+++ b/aadarchi-maven-plugin/src/it/2_generate_html_docs/src/docs/asciidoc/01-context.adoc
@@ -0,0 +1,22 @@
+= Context
+:chapter: Context
+include::_notify-bug-admonition.adoc[]
+
+agile-architecture-documentation-system tries to provide a solution to a rather usual, but not so well solved, problem:
+how to document architecture of a software system with the minimal effort and the maximal result.
+As a consequence, this product tries to help the architect in all possible ways.
+
+== Context diagram
+// This is an example diagram to show how to include a structurizr-generated diagram
+[plantuml, {plantumldir}SystemContext, svg, opts="interactive"]
+----
+include::{structurizrdir}/SystemContext.plantuml[]
+----
+
+We identify different user profiles:
+
+* the architect as a scribe role, which is responsible for maintaining a correct documentation of the architecture
+* the various stakeholders, be them developers, product owners, ops teams, and so on, which will refer to the produced documentation as an entrypoint.
+
+// This include allows enhancers to have their content include "automagically". Don't remove it!
+include::{enhancements-dir}/_01-context.adoc[leveloffset=+1]
\ No newline at end of file
diff --git a/aadarchi-maven-plugin/src/it/2_generate_html_docs/src/docs/asciidoc/02-functional_overview.adoc b/aadarchi-maven-plugin/src/it/2_generate_html_docs/src/docs/asciidoc/02-functional_overview.adoc
new file mode 100644
index 00000000..9676c0bc
--- /dev/null
+++ b/aadarchi-maven-plugin/src/it/2_generate_html_docs/src/docs/asciidoc/02-functional_overview.adoc
@@ -0,0 +1,79 @@
+= Functional Overview
+:chapter: Functional%20Overview
+include::_notify-bug-admonition.adoc[]
+
+This software helps the architect writing a coherent, complete and readable software architecture documentation.
+Usage of this software is quite simple (for a developer).
+
+The first step is to initiate a documentation (which is documented in https://github.com/Riduidel/agile-architecture-documentation-system#install[README.md]).
+
+Then, architect has to write content in all `.adoc` files generated in `src/docs/asciidoc`.
+Notice writing those files will be eased out by using the `Architecture` java class to generate diagrams,
+and the enhancers this project provides.
+
+The enhancers allows architect to have content added to this documentation without having to write it himself.
+Typically, we're able to include README documents, architecture decisions, and more to come later ... (well, provided the users ask for additionnal includes)
+
+////
+Even though the purpose of technical software documentation isn't to
+explain what the software does in detail, it can be useful to expand on
+the link:/help/documentation/context[context] and summarise what the
+major functions of the software are.
+
+== Intent
+
+This section allows you to summarise what the key functions of the
+system are (use cases, user stories, etc). A functional overview should
+answer the following types of questions:
+
+* Is it clear what the system actually does?
+* Is it clear who the important users are (roles, actors, personas, etc)
+and how the system caters for their needs?
+
+Alternatively, if your software automates a business process or
+workflow, a functional view should answer questions like the following:
+
+* Is it clear what the system does from a process perspective?
+* What are the major processes and flows of information through the
+system?
+
+== Structure
+
+By all means refer to existing documentation if it's available, whether
+that's in the form of functional specifications, use case documents,
+lists of user stories, etc. However, it's often useful to summarise the
+business domain and the functionality provided by the system. Again,
+diagrams can help, and you could use a UML use case diagram or a
+collection of simple wireframes showing the important parts of the user
+interface. Either way, the purpose of this section is to provide a
+functional _overview_.
+
+Alternatively, if your software automates a business process or
+workflow, you could use a flow chart or UML activity diagram to show the
+smaller steps within the process and how they fit together. This is
+particularly useful to highlight aspects such as parallelism,
+concurrency, where businesses processes fork or join, etc.
+
+== Motivation
+
+This doesn't necessarily need to be a long section, with diagrams being
+used to provide an overview. Where a
+link:/help/documentation/context[context section] summarises how the
+software fits into the existing environment, this section describes what
+the system actually does. Again, this is about providing a summary and
+setting the scene rather than comprehensively describing every
+user/system interaction.
+
+== Audience
+
+Technical and non-technical people, inside and outside of the immediate
+software development team.
+
+== Required
+
+Yes, all software documentation should include a summary of the
+functionality provided by the software.
+////
+
+// This include allows enhancers to have their content include "automagically". Don't remove it!
+include::{enhancements-dir}/_02-functional_overview.adoc[leveloffset=+1]
\ No newline at end of file
diff --git a/aadarchi-maven-plugin/src/it/2_generate_html_docs/src/docs/asciidoc/03-quality_attributes.adoc b/aadarchi-maven-plugin/src/it/2_generate_html_docs/src/docs/asciidoc/03-quality_attributes.adoc
new file mode 100644
index 00000000..4bfaeadf
--- /dev/null
+++ b/aadarchi-maven-plugin/src/it/2_generate_html_docs/src/docs/asciidoc/03-quality_attributes.adoc
@@ -0,0 +1,128 @@
+= Quality Attributes
+:chapter: Quality%20Attributes
+include::_notify-bug-admonition.adoc[]
+
+The documentation build should be fast enough to allow architect to write its documentation
+and have it reloaded in "human real time".
+In other words, we expect
+a simple documentation to generate in less than 10 seconds
+and
+a complex documentation (involving reading configuration from remote systems and so on) to generate in less than 1 minute.
+**TODO**
+////
+With the link:/help/documentation/functional-overview[functional
+overview section] summarising the functionality, it's also worth
+including a separate section to summarise the quality attributes (also
+referred to as "non-functional requirements").
+
+== Intent
+
+This section is about summarising the key quality attributes and should
+answer the following types of questions:
+
+* Is there a clear understanding of the quality attributes that the
+architecture must satisfy?
+* Are the quality attributes SMART (specific, measurable, achievable,
+relevant and timely)?
+* Have quality attributes that are usually taken for granted been
+explicitly marked as out of scope if they are not needed? (e.g. "user
+interface elements will only be presented in English" to indicate that
+multi-language support is not explicitly catered for)
+* Are any of the quality attributes unrealistic? (e.g. true 24x7
+availability is typically very costly to implement inside many
+organisations)
+
+In addition, if any of the quality attributes are deemed as
+"architecturally significant" and therefore influence the architecture,
+why not make a note of them so that you can refer back to them later in
+the documentation.
+
+== Structure
+
+Simply listing out each of the quality attributes is a good starting
+point. Examples include:
+
+Performance (e.g. latency and throughput)::
+TODO
+
+Scalability (e.g. data and traffic volumes)::
+TODO
+
+Availability (e.g. uptime, downtime, scheduled maintenance, 24x7, 99.9%, etc)::
+TODO
+
+Security (e.g. authentication, authorisation, data confidentiality, etc)::
+TODO
+
+Extensibility::
+TODO
+
+Flexibility::
+TODO
+
+Auditing::
+TODO
+
+Monitoring and management::
+TODO
+
+Reliability::
+TODO
+
+Failover/disaster recovery targets (e.g. manual vs automatic, how long will this take?)::
+TODO
+
+Business continuity::
+TODO
+
+Interoperability::
+TODO
+
+Legal, compliance and regulatory requirements (e.g. data protection act)::
+TODO
+
+Internationalisation (i18n) and localisation (L10n)::
+TODO
+
+Accessibility::
+TODO
+
+Usability::
+TODO
+
+== ...
+
+Each quality attribute should be precise, leaving no interpretation to
+the reader. Examples where this isn't the case include:
+
+* "the request must be serviced quickly"
+* "there should be no overhead"
+* "as fast as possible"
+* "as small as possible"
+* "as many customers as possible"
+* ...
+
+== Motivation
+
+If you've proactively considered the quality attributes and let them
+influence the software architecture, why not write them down too?
+Typically, quality attributes are not given to you on a plate and an
+amount of exploration and refinement is usually needed to come up with a
+list of them. Put simply, writing down the quality attributes removes
+any ambiguity both now and during maintenance/enhancement work in the
+future.
+
+== Audience
+
+Since quality attributes are mostly technical in nature, this section is
+really targeted at technical people in the software development team.
+
+== Required
+
+Yes, all technical software documentation should include a summary of
+the quality attributes/non-functional requirements as they usually shape
+the resulting software architecture in some way.
+////
+
+// This include allows enhancers to have their content include "automagically". Don't remove it!
+include::{enhancements-dir}/_03-quality_attributes.adoc[leveloffset=+1]
\ No newline at end of file
diff --git a/aadarchi-maven-plugin/src/it/2_generate_html_docs/src/docs/asciidoc/04-constraints.adoc b/aadarchi-maven-plugin/src/it/2_generate_html_docs/src/docs/asciidoc/04-constraints.adoc
new file mode 100644
index 00000000..e106a931
--- /dev/null
+++ b/aadarchi-maven-plugin/src/it/2_generate_html_docs/src/docs/asciidoc/04-constraints.adoc
@@ -0,0 +1,97 @@
+= Constraints
+:chapter: Constraints
+include::_notify-bug-admonition.adoc[]
+
+**TODO**
+////
+Software lives within the context of the real-world, and the real-world
+has constraints. This section allows you to state these constraints so
+it's clear that you are working within them and obvious how they affect
+your architecture decisions.
+
+== Intent
+
+Constraints are typically imposed upon you but they aren't necessarily
+"bad", as reducing the number of available options often makes your job
+designing software easier. This section allows you to explicitly
+summarise the constraints that you're working within and the decisions
+that have already been made for you.
+
+== Structure
+
+As with the link:/help/documentation/quality-attributes[quality
+attributes section], simply listing the known constraints and briefly
+summarising them will work. Example constraints include:
+
+Time, budget and resources::
+TODO
+
+Approved technology lists and technology constraints::
+TODO
+
+Target deployment platform::
+TODO
+
+Existing systems and integration standards::
+TODO
+
+Local standards (e.g. development, coding, etc)::
+TODO
+
+Public standards (e.g. HTTP, SOAP, XML, XML Schema, WSDL, etc)::
+TODO
+
+Standard protocols::
+TODO
+
+Standard message formats::
+TODO
+
+Size of the software development team::
+TODO
+
+Skill profile of the software development team::
+TODO
+
+Nature of the software being built (e.g. tactical or strategic)::
+TODO
+
+Political constraints::
+TODO
+
+Use of internal intellectual property::
+TODO
+
+...::
+TODO
+
+
+If constraints do have an impact, it's worth summarising them (e.g. what
+they are, why they are being imposed and who is imposing them) and
+stating how they are significant to your architecture.
+
+== Motivation
+
+Constraints have the power to massively influence the architecture,
+particularly if they limit the technology that can be used to build the
+solution. Documenting them prevents you having to answer questions in
+the future about why you've seemingly made some odd decisions.
+
+== Audience
+
+The audience for this section includes everybody involved with the
+software development process, since some constraints are technical and
+some aren't.
+
+== Required
+
+Yes, all technical software documentation should include a summary of
+the constraints as they usually shape the resulting software
+architecture in some way. It's worth making these constraints explicit
+at all times, even in environments that have a very well known set of
+constraints (e.g. "all of our software is ASP.NET against a SQL Server
+database") because constraints have a habit of changing over time.
+////
+
+// This include allows enhancers to have their content include "automagically". Don't remove it!
+include::{enhancements-dir}/_04-constraints.adoc[leveloffset=+1]
\ No newline at end of file
diff --git a/aadarchi-maven-plugin/src/it/2_generate_html_docs/src/docs/asciidoc/05-principles.adoc b/aadarchi-maven-plugin/src/it/2_generate_html_docs/src/docs/asciidoc/05-principles.adoc
new file mode 100644
index 00000000..b0590c0d
--- /dev/null
+++ b/aadarchi-maven-plugin/src/it/2_generate_html_docs/src/docs/asciidoc/05-principles.adoc
@@ -0,0 +1,71 @@
+= Principles
+:chapter: Principles
+include::_notify-bug-admonition.adoc[]
+
+* Architecture model must be totally described in the Architecture class.
+* Additional architecture information (typically, location of README files for components) has to be set has properties in the various Structurizr `Element` subclasses (`SoftwareSystem`, `Container`, `Component`)
+
+////
+The principles section allows you to summarise those principles that
+have been used (or you are using) to design and build the software.
+
+== Intent
+
+The purpose of this section is to simply make it explicit which
+principles you are following. These could have been explicitly asked for
+by a stakeholder or they could be principles that _you_ (i.e. the
+software development team) want to adopt and follow.
+
+== Structure
+
+If you have an existing set of software development principles (e.g. on
+a development wiki), by all means simply reference it. Otherwise, list
+out the principles that you are following and accompany each with a
+short explanation or link to further information. Example principles
+include:
+
+* Architectural layering strategy.
+* No business logic in views.
+* No database access in views.
+* Use of interfaces.
+* Always use an ORM.
+* Dependency injection.
+* The Hollywood principle (don't call us, we'll call you).
+* High cohesion, low coupling.
+* Follow
+https://en.wikipedia.org/wiki/SOLID_(object-oriented_design)[SOLID]
+(Single responsibility principle, Open/closed principle, Liskov
+substitution principle, Interface segregation principle, Dependency
+inversion principle).
+* DRY (don't repeat yourself).
+* Ensure all components are stateless (e.g. to ease scaling).
+* Prefer a rich domain model.
+* Prefer an anaemic domain model.
+* Always prefer stored procedures.
+* Never use stored procedures.
+* Don't reinvent the wheel.
+* Common approaches for error handling, logging, etc.
+* Buy rather than build.
+* ...
+
+== Motivation
+
+The motivation for writing down the list of principles is to make them
+explicit so that everybody involved with the software development
+understands what they are. Why? Put simply, principles help to introduce
+consistency into a codebase by ensuring that common problems are
+approached in the same way.
+
+== Audience
+
+The audience for this section is predominantly the technical people in
+the software development team.
+
+== Required
+
+Yes, all technical software documentation should include a summary of
+the principles that have been or are being used to develop the software.
+////
+
+// This include allows enhancers to have their content include "automagically". Don't remove it!
+include::{enhancements-dir}/_05-principles.adoc[leveloffset=+1]
\ No newline at end of file
diff --git a/aadarchi-maven-plugin/src/it/2_generate_html_docs/src/docs/asciidoc/06-software_architecture.adoc b/aadarchi-maven-plugin/src/it/2_generate_html_docs/src/docs/asciidoc/06-software_architecture.adoc
new file mode 100644
index 00000000..7dc73446
--- /dev/null
+++ b/aadarchi-maven-plugin/src/it/2_generate_html_docs/src/docs/asciidoc/06-software_architecture.adoc
@@ -0,0 +1,69 @@
+= Software Architecture
+:chapter: Software%20Architecture
+include::_notify-bug-admonition.adoc[]
+
+[plantuml, {plantumldir}SystemContainers, svg, opts="interactive"]
+----
+include::{structurizrdir}/SystemContainers.plantuml[]
+----
+
+[plantuml, {plantumldir}baseComponents, svg, opts="interactive"]
+----
+include::{structurizrdir}/baseComponents.plantuml[]
+----
+
+**TODO**
+////
+The software architecture section is your "big picture" view and allows
+you to present the structure of the software. Traditional software
+architecture documents typically refer to this as a "conceptual view" or
+"logical view", and there is often confusion about whether such views
+should refer to implementation details such as technology choices.
+
+== Intent
+
+The purpose of this section is to summarise the software architecture of
+your software system so that the following questions can be answered:
+
+* What does the "big picture" look like?
+* Is there are clear structure?
+* Is it clear how the system works from the "30,000 foot view"?
+* Does it show the major containers and technology choices?
+* Does it show the major components and their interactions?
+* What are the key internal interfaces? (e.g. a web service between your
+web and business tiers)
+
+== Structure
+
+The link:/help/static-diagrams[container and component diagrams]
+diagrams are the main focus for this section, accompanied by a short
+narrative explaining what the diagram is showing plus a summary of each
+container/component.
+
+Sometimes UML sequence or collaboration diagrams showing component
+interactions can be a useful way to illustrate how the software
+satisfies the major use cases/user stories/etc. Only do this if it adds
+value though and resist the temptation to describe how every use
+case/user story works.
+
+== Motivation
+
+The motivation for writing this section is that it provides the "maps"
+that people can use to get an overview of the software and help
+developers navigate the codebase.
+
+== Audience
+
+The audience for this section is predominantly the technical people in
+the software development team.
+
+== Required
+
+Yes, all technical software documentation should include a software
+architecture section because it's essential that the overall software
+structure is well understood by everybody on the development team.
+////
+
+
+// This include allows enhancers to have their content include "automagically". Don't remove it!
+include::{enhancements-dir}/_06-software_architecture.adoc[leveloffset=+1]
\ No newline at end of file
diff --git a/aadarchi-maven-plugin/src/it/2_generate_html_docs/src/docs/asciidoc/07-code.adoc b/aadarchi-maven-plugin/src/it/2_generate_html_docs/src/docs/asciidoc/07-code.adoc
new file mode 100644
index 00000000..5dd32dc5
--- /dev/null
+++ b/aadarchi-maven-plugin/src/it/2_generate_html_docs/src/docs/asciidoc/07-code.adoc
@@ -0,0 +1,77 @@
+= Code
+:chapter: Code
+include::_notify-bug-admonition.adoc[]
+
+////
+Although other sections of the documentation describe the overall
+architecture of the software, often you'll want to present lower level
+details to explain how things work. This is what the code section is
+for. Some software architecture documentation templates call this the
+"implementation view" or the "development view".
+
+== Intent
+
+The purpose of the code section is to describe the implementation
+details for parts of the software system that are important, complex,
+significant, etc. Examples include:
+
+* Generating/rendering HTML: a short description of the framework that
+was created for generating HTML, including the major classes and
+concepts.
+* Data binding: the approach to updating business objects as the result
+of HTTP POST requests.
+* Multi-page data collection: a short description of the framework used
+for building forms that spanned multiple web pages.
+* Web MVC: an example usage of the web MVC framework being used.
+* Security: the approach to using Windows Identity Foundation (WIF) for
+authentication and authorisation.
+* Domain model: an overview of the important parts of the domain model.
+* Component framework: a short description of the framework that we
+built to allow components to be reconfigured at runtime.
+* Configuration: a short description of the standard component
+configuration mechanism in use across the codebase.
+* Architectural layering: an overview of the layering strategy and the
+patterns in use to implement it.
+* Exceptions and logging: a summary of the approach to exception
+handling and logging across the various architectural layers.
+* Patterns and principles: an explanation of how patterns and
+link:/help/documentation/principles[principles] are implemented.
+* ...
+
+== Structure
+
+Keep it simple, with a short section for each element that you want to
+describe and include diagrams if they help the reader. For example, a
+high-level UML class and/or sequence diagram can be useful to help
+explain how a bespoke/hand-written in-house framework works. Resist the
+temptation to include all of the detail though, and don't feel that your
+diagrams need to show everything. Instead, spend a few minutes sketching
+out a high-level UML class diagram that shows selected (important)
+attributes and methods rather than using the complex diagrams that can
+be generated automatically from your codebase with UML tools or IDE
+plugins. Keeping any diagrams at a high-level of detail means that
+they're less volatile and remain up to date for longer because they can
+tolerate small changes to the code and yet remain valid.
+
+== Motivation
+
+The motivation for writing this section is to ensure that everybody
+understands how the important/significant/complex parts of the software
+system work so that they can maintain, enhance and extend them in a
+consistent and coherent manner. This section also helps new members of
+the team get up to speed quickly.
+
+== Audience
+
+The audience for this section is predominantly the technical people in
+the software development team.
+
+=== Required
+
+No, but there are usually parts of a large, non-trivial software system
+that can benefit from some explanation.
+////
+
+
+// This include allows enhancers to have their content include "automagically". Don't remove it!
+include::{enhancements-dir}/_07-code.adoc[leveloffset=+1]
\ No newline at end of file
diff --git a/aadarchi-maven-plugin/src/it/2_generate_html_docs/src/docs/asciidoc/08-data.adoc b/aadarchi-maven-plugin/src/it/2_generate_html_docs/src/docs/asciidoc/08-data.adoc
new file mode 100644
index 00000000..d382c0ab
--- /dev/null
+++ b/aadarchi-maven-plugin/src/it/2_generate_html_docs/src/docs/asciidoc/08-data.adoc
@@ -0,0 +1,59 @@
+= Data
+:chapter: Data
+include::_notify-bug-admonition.adoc[]
+
+Application hosts no data other, since verything is in the Maven folder.
+////
+The data associated with a software system is usually not the primary
+point of focus yet it's arguably more important than the software
+itself, so often it's useful to document something about it.
+
+== Intent
+
+The purpose of the data section is to record anything that is important
+from a data perspective, answering the following types of questions:
+
+* What does the data model look like?
+* Where is data stored?
+* Who owns the data?
+* How much storage space is needed for the data? (e.g. especially if you're dealing with "big data")
+* What are the archiving and back-up strategies?
+* Are there any regulatory requirements for the long term archival of business data?
+* Likewise for log files and audit trails?
+* Are flat files being used for storage? If so, what format is being used?
+
+== Structure
+
+Keep it simple, with a short section for each element that you want to
+describe and include domain models or entity relationship diagrams if
+they help the reader. As with the advice for including class diagrams in
+the link:/help/documentation/code[code section], keep any diagrams at a
+high level of abstraction rather than including every field and
+property. If people need this type of information, they can find it in
+the code or database (for example).
+
+== Motivation
+
+The motivation for writing this section is that the data in most
+software systems tends to outlive the software. This section can help
+anybody that needs to maintain and support the data on an ongoing basis,
+plus anybody that needs to extract reports or undertake business
+intelligence activities on the data. This section can also serve as a
+starting point for when the software system is inevitably rewritten in
+the future.
+
+== Audience
+
+The audience for this section is predominantly the technical people in
+the software development team along with others that may help deploy,
+support and operate the software system.
+
+== Required
+
+No, but most software systems are not small or trivial, and the data
+will likely outlive the code that created it.
+////
+
+
+// This include allows enhancers to have their content include "automagically". Don't remove it!
+include::{enhancements-dir}/_08-data.adoc[leveloffset=+1]
\ No newline at end of file
diff --git a/aadarchi-maven-plugin/src/it/2_generate_html_docs/src/docs/asciidoc/09-infrastructure_architecture.adoc b/aadarchi-maven-plugin/src/it/2_generate_html_docs/src/docs/asciidoc/09-infrastructure_architecture.adoc
new file mode 100644
index 00000000..7ce9cfbc
--- /dev/null
+++ b/aadarchi-maven-plugin/src/it/2_generate_html_docs/src/docs/asciidoc/09-infrastructure_architecture.adoc
@@ -0,0 +1,60 @@
+= Infrastructure Architecture
+:chapter: Infrastructure%20Architecture
+include::_notify-bug-admonition.adoc[]
+
+The main goal of this application is to produce content that can be browsed as HTML or PDF.
+As a consequence, there is no requirement for any production infrastructure.
+////
+While most of the documentation is focused on the software itself, we do
+also need to consider the infrastructure because software architecture
+is about software _and_ infrastructure.
+
+== Intent
+
+This section is used to describe the physical/virtual hardware and
+networks on which the software will be deployed. Although, as a software
+architect, you may not be involved in designing the infrastructure, you
+do need to understand that it's sufficient to enable you to satisfy your
+goals. The purpose of this section is to answer the following types of
+questions:
+
+* Is there a clear physical architecture?
+* What hardware (virtual or physical) does this include across all tiers?
+* Does it cater for redundancy, failover and disaster recovery if applicable?
+* Is it clear how the chosen hardware components have been sized and selected?
+* If multiple servers and sites are used, what are the network links between them?
+* Who is responsible for support and maintenance of the infrastructure?
+* Are there central teams to look after common infrastructure (e.g.
+databases, message buses, application servers, networks, routers,
+switches, load balancers, reverse proxies, internet connections, etc)?
+* Who owns the resources?
+* Are there sufficient environments for development, testing, acceptance, pre-production, production, etc?
+
+== Structure
+
+The main focus for this section is usually an infrastructure/network
+diagram showing the various hardware/network components (servers,
+routers, firewalls, load balancers, etc) and how they fit together, with
+a short narrative to accompany the diagram.
+
+== Motivation
+
+The motivation for writing this section is to document the
+infrastructure and confirm that it supports the software architecture.
+
+== Audience
+
+The audience for this section is predominantly the technical people in
+the software development team along with others that may help deploy,
+support and operate the software system.
+
+== Required
+
+Yes, an infrastructure architecture section should be included in
+technical software documentation because it illustrates that the
+infrastructure is understood and has been considered.
+////
+
+
+// This include allows enhancers to have their content include "automagically". Don't remove it!
+include::{enhancements-dir}/_09-infrastructure_architecture.adoc[leveloffset=+1]
\ No newline at end of file
diff --git a/aadarchi-maven-plugin/src/it/2_generate_html_docs/src/docs/asciidoc/10-deployment.adoc b/aadarchi-maven-plugin/src/it/2_generate_html_docs/src/docs/asciidoc/10-deployment.adoc
new file mode 100644
index 00000000..0bbbd00c
--- /dev/null
+++ b/aadarchi-maven-plugin/src/it/2_generate_html_docs/src/docs/asciidoc/10-deployment.adoc
@@ -0,0 +1,71 @@
+= Deployment
+:chapter: Deployment
+include::_notify-bug-admonition.adoc[]
+
+Deployment of the agile-architecture-documentation code is done by pushing code to GitHub.
+On push, there is a https://github.com/Riduidel/agile-architecture-documentation-system/actions?query=workflow%3A%22Java+CI+with+Maven%22[GitHub action] (defined in https://github.com/Riduidel/agile-architecture-documentation-system/blob/master/.github/workflows/build.yml[main module .github folder]) which will compile everything and generate the github pages.
+////
+The deployment section is simply the mapping between the
+<> and the <>.
+
+== Intent
+
+This section is used to describe the mapping between the software (e.g.
+containers) and the infrastructure. Sometimes this will be a simple
+one-to-one mapping (e.g. deploy a web application to a single web
+server) and at other times it will be more complex (e.g. deploy a web
+application across a number of servers in a server farm). This section
+answers the following types of questions:
+
+* How and where is the software installed and configured?
+* Is it clear how the software will be deployed across the infrastructure elements described in the link:/help/documentation/<>? (e.g. one-to-one mapping, multiple containers per server, etc)
+* If this is still to be decided, what are the options and have they been documented?
+* Is it understood how memory and CPU will be partitioned between the processes running on a single piece of infrastructure?
+* Are any containers and/or components running in an active-active, active-passive, hot-standby, cold-standby, etc formation?
+* Has the deployment and rollback strategy been defined?
+* What happens in the event of a software or infrastructure failure?
+* Is it clear how data is replicated across sites?
+
+== Structure
+
+There are a few ways to structure this section:
+
+. Tables: simple textual tables that show the mapping between software
+containers and/or components with the infrastructure they will be
+deployed on.
+. Diagrams: UML deployment diagrams or modified versions of the diagrams
+from the
+link:/help/documentation/<> showing where software will be running.
+
+You can additionally use notation, colour coding, etc to the designate
+the runtime status of software and infrastructure (e.g. active, passive,
+hot-standby, warm-standby, cold-standby, etc).
+
+== Motivation
+
+The motivation for writing this section is to ensure that everybody
+understands how the software is going to work once it gets out of the
+development environment and also to document the often complex
+deployment of enterprise software systems.
+
+This section can provide a useful overview, even for those teams that
+have adopted https://continuousdelivery.com[continuous delivery] and
+have all of their deployment scripted using tools such as Puppet, Chef,
+Vagrant, Docker, etc.
+
+== Audience
+
+The audience for this section is predominantly the technical people in
+the software development team along with others that may help deploy,
+support and operate the software system.
+
+== Required
+
+Yes, a deployment section should be included in all technical software
+documentation because it can help to solve the often mysterious question
+of where the software will be, or has been, deployed.
+////
+
+
+// This include allows enhancers to have their content include "automagically". Don't remove it!
+include::{enhancements-dir}/_10-deployment.adoc[leveloffset=+1]
\ No newline at end of file
diff --git a/aadarchi-maven-plugin/src/it/2_generate_html_docs/src/docs/asciidoc/11-development_environment.adoc b/aadarchi-maven-plugin/src/it/2_generate_html_docs/src/docs/asciidoc/11-development_environment.adoc
new file mode 100644
index 00000000..707b54c2
--- /dev/null
+++ b/aadarchi-maven-plugin/src/it/2_generate_html_docs/src/docs/asciidoc/11-development_environment.adoc
@@ -0,0 +1,78 @@
+= Development Environment
+:chapter: Development%20Environment
+include::_notify-bug-admonition.adoc[]
+
+Development of this documentation solution requires a Java environnment.
+In other words, you need
+
+* A recent JDK (at least Java 11)
+* Maven (at least version 3.6)
+* A Java IDE
+
+Optionally, things will be better if you have
+* an Asciidoc editor
+* a http://livereload.com/extensions/[livereload compatible browser]
+
+////
+The development environment section allows you to summarise how people
+new to your team install tools and setup a development environment in
+order to work on the software.
+
+== Intent
+
+The purpose of this section is to provide instructions that take
+somebody from a blank operating system installation to a fully-fledged
+development environment.
+
+== Structure
+
+The type of things you might want to include are:
+
+Pre-requisite versions of software needed::
+TODO
+Links to software downloads (either on the Internet or locally stored)::
+TODO
+Links to virtual machine images::
+TODO
+Environment variables, Windows registry settings, etc::
+TODO
+Host name entries::
+TODO
+IDE configuration::
+TODO
+Build and test instructions::
+TODO
+Database population scripts::
+TODO
+Usernames, passwords and certificates for connecting to development and test services::
+TODO
+Links to build servers::
+TODO
+Thinking about anything else?::
+TODO
+
+If you're using automated solutions (such as Vagrant, Docker, Puppet,
+Chef, Rundeck, etc), it's still worth including some brief information
+about how these solutions work, where to find the scripts and how to run
+them.
+
+== Motivation
+
+The motivation for this section is to ensure that new developers can be
+productive as quickly as possible.
+
+== Audience
+
+The audience for this section is the technical people in the software
+development team, especially those who are new to the team.
+
+== Required
+
+Yes, because this information is usually lost and it's essential if the
+software will be maintained by a different set of people from the
+original developers.
+////
+
+
+// This include allows enhancers to have their content include "automagically". Don't remove it!
+include::{enhancements-dir}/_11-development_environment.adoc[leveloffset=+1]
\ No newline at end of file
diff --git a/aadarchi-maven-plugin/src/it/2_generate_html_docs/src/docs/asciidoc/12-operation_and_support.adoc b/aadarchi-maven-plugin/src/it/2_generate_html_docs/src/docs/asciidoc/12-operation_and_support.adoc
new file mode 100644
index 00000000..c3a4f24f
--- /dev/null
+++ b/aadarchi-maven-plugin/src/it/2_generate_html_docs/src/docs/asciidoc/12-operation_and_support.adoc
@@ -0,0 +1,57 @@
+= Operation and Support
+:chapter: Operation%20and%20Support
+include::_notify-bug-admonition.adoc[]
+
+**TODO**
+////
+The operations and support section allows you to describe how people
+will run, monitor and manage your software.
+
+== Intent
+
+Most systems will be subject to support and operational requirements,
+particularly around how they are monitored, managed and administered.
+Including a dedicated section in the software guidebook lets you be
+explicit about how your software will or does support those
+requirements. This section should address the following types of
+questions:
+
+* Is it clear how the software provides the ability for
+operation/support teams to monitor and manage the system?
+* How is this achieved across all tiers of the architecture?
+* How can operational staff diagnose problems?
+* Where are errors and information logged? (e.g. log files, Windows
+Event Log, SMNP, JMX, WMI, custom diagnostics, etc)
+* Do configuration changes require a restart?
+* Are there any manual housekeeping tasks that need to be performed on a
+regular basis?
+* Does old data need to be periodically archived?
+
+== Structure
+
+This section is usually fairly narrative in nature, with a heading for
+each related set of information (e.g. monitoring, diagnostics,
+configuration, etc).
+
+== Motivation
+
+Times change and team members move on, so recording this information can
+help prevent those situations in the future where nobody understands how
+to operate the software. It also helps to quickly answer basic questions
+such as, "where are the log files?".
+
+== Audience
+
+The audience for this section is predominantly the technical people in
+the software development team along with others that may help deploy,
+support and operate the software system.
+
+== Required
+
+Yes, an operations and support section should be included in all
+technical software documentation, unless you like throwing software into
+a black hole and hoping for the best.
+////
+
+// This include allows enhancers to have their content include "automagically". Don't remove it!
+include::{enhancements-dir}/_12-operation_and_support.adoc[leveloffset=+1]
\ No newline at end of file
diff --git a/aadarchi-maven-plugin/src/it/2_generate_html_docs/src/docs/asciidoc/13-decision_log.adoc b/aadarchi-maven-plugin/src/it/2_generate_html_docs/src/docs/asciidoc/13-decision_log.adoc
new file mode 100644
index 00000000..9f738cdf
--- /dev/null
+++ b/aadarchi-maven-plugin/src/it/2_generate_html_docs/src/docs/asciidoc/13-decision_log.adoc
@@ -0,0 +1,40 @@
+= Decision Log
+:chapter: Decision%20Log
+include::_notify-bug-admonition.adoc[]
+
+include::13-decision_log/001_use_adr.adoc[leveloffset=+1]
+
+////
+
+== Motivation
+
+The motivation for recording the significant decisions is that this
+section can act as a point of reference in the future. All decisions are
+made given a specific context and usually have trade-offs. There is
+usually never a perfect solution to a given problem. Articulating the
+decision making process after the event is often complex, particularly
+if you're explaining the decision to people who are joining the team or
+you're in an environment where the context changes on a regular basis.
+
+Although "nobody ever gets fired for buying IBM", perhaps writing down
+the fact that corporate policy forced you into using IBM WebSphere over
+Apache Tomcat will save you some tricky conversations in the future.
+
+== Audience
+
+The audience for this section is predominantly the technical people in
+the software development team along with others that may help deploy,
+support and operate the software system.
+
+== Required
+
+No, but it can be useful to include this section if the team spend more
+than a few minutes thinking about something significant such as a
+technology choice or an architectural style. If in doubt, spend a couple
+of minutes writing it down, especially if you work for a consulting
+organisation who is building a software system under an outsourcing
+agreement for a customer.
+////
+
+// This include allows enhancers to have their content include "automagically". Don't remove it!
+include::{enhancements-dir}/_13-decision_log.adoc[leveloffset=+1]
\ No newline at end of file
diff --git a/aadarchi-maven-plugin/src/it/2_generate_html_docs/src/docs/asciidoc/_notify-bug-admonition.adoc b/aadarchi-maven-plugin/src/it/2_generate_html_docs/src/docs/asciidoc/_notify-bug-admonition.adoc
new file mode 100644
index 00000000..75604ee1
--- /dev/null
+++ b/aadarchi-maven-plugin/src/it/2_generate_html_docs/src/docs/asciidoc/_notify-bug-admonition.adoc
@@ -0,0 +1,35 @@
+:project-pom-path: ../../../pom.xml
+////
+TODO: if your project don't use GitHub, change the base URL to fit your needs
+////
+
+ifeval::["{hideBugReport}"!="true"]
+ifeval::["{project-issues-on-github}"!=""]
+[TIP]
+If you encounter any error, feel free to
+https://github.com/Riduidel/agile-architecture-documentation-system/issues/new?title=Error%20in%20{project-artifact-id}%20v.{project-version}%20chapter%20{chapter}[icon:github[set=fab] enter an issue on GitHub,window=feedback].
+endif::[]
+ifeval::["{project-issues-not-defined}"!=""]
+[WARNING]
+====
+If you want to have a nice bug report page on each chapter, you can do the following
+
+First, change the value in `` to be your issues server one. Currently, it is defined there:
+
+[source, xml]
+----
+include::{project-pom-path}[tag=issues-url, indent=0]
+----
+
+Then, define the type of bug tracking software you use here
+
+[source, xml]
+----
+include::{project-pom-path}[tag=bug-tracking-define, indent=0]
+----
+
+If you don't want that feature, just set ` or `asciidoc.documents.hide.bug.report` property to `true`.
+
+====
+endif::[]
+endif::[]
diff --git a/aadarchi-maven-plugin/src/it/2_generate_html_docs/src/docs/asciidoc/index.adoc b/aadarchi-maven-plugin/src/it/2_generate_html_docs/src/docs/asciidoc/index.adoc
new file mode 100644
index 00000000..e0471b83
--- /dev/null
+++ b/aadarchi-maven-plugin/src/it/2_generate_html_docs/src/docs/asciidoc/index.adoc
@@ -0,0 +1,33 @@
+
+:toc:
+:toclevels: 5
+:doctype: book
+
+= {project-name}
+
+include::01-context.adoc[leveloffset=+1]
+
+include::02-functional_overview.adoc[leveloffset=+1]
+
+include::03-quality_attributes.adoc[leveloffset=+1]
+
+include::04-constraints.adoc[leveloffset=+1]
+
+include::05-principles.adoc[leveloffset=+1]
+
+include::06-software_architecture.adoc[leveloffset=+1]
+
+include::07-code.adoc[leveloffset=+1]
+
+include::08-data.adoc[leveloffset=+1]
+
+include::09-infrastructure_architecture.adoc[leveloffset=+1]
+
+include::10-deployment.adoc[leveloffset=+1]
+
+include::11-development_environment.adoc[leveloffset=+1]
+
+include::12-operation_and_support.adoc[leveloffset=+1]
+
+include::13-decision_log.adoc[leveloffset=+1]
+
diff --git a/aadarchi-maven-plugin/src/it/2_generate_html_docs/verify.groovy b/aadarchi-maven-plugin/src/it/2_generate_html_docs/verify.groovy
new file mode 100644
index 00000000..9a692b20
--- /dev/null
+++ b/aadarchi-maven-plugin/src/it/2_generate_html_docs/verify.groovy
@@ -0,0 +1 @@
+assert new File(basedir, "target/foo/index.html").exists()
\ No newline at end of file
diff --git a/aadarchi-maven-plugin/src/main/java/org/ndx/agile/architecture/documentation/system/maven/plugin/GenerateHtmlDocs.java b/aadarchi-maven-plugin/src/main/java/org/ndx/agile/architecture/documentation/system/maven/plugin/GenerateHtmlDocs.java
new file mode 100644
index 00000000..596f7c53
--- /dev/null
+++ b/aadarchi-maven-plugin/src/main/java/org/ndx/agile/architecture/documentation/system/maven/plugin/GenerateHtmlDocs.java
@@ -0,0 +1,96 @@
+package org.ndx.agile.architecture.documentation.system.maven.plugin;
+
+import org.apache.maven.execution.MavenSession;
+import org.apache.maven.plugin.AbstractMojo;
+import org.apache.maven.plugin.BuildPluginManager;
+import org.apache.maven.plugin.MojoExecutionException;
+import org.apache.maven.plugin.MojoFailureException;
+import org.apache.maven.plugins.annotations.Component;
+import org.apache.maven.plugins.annotations.LifecyclePhase;
+import org.apache.maven.plugins.annotations.Mojo;
+import org.apache.maven.plugins.annotations.Parameter;
+import org.apache.maven.project.MavenProject;
+
+import static org.twdata.maven.mojoexecutor.MojoExecutor.*;
+
+@Mojo(name = "generate-html-docs", defaultPhase = LifecyclePhase.PREPARE_PACKAGE)
+public class GenerateHtmlDocs extends AbstractMojo {
+ @Component
+ private MavenProject mavenProject;
+
+ @Component
+ private MavenSession mavenSession;
+
+ @Component
+ private BuildPluginManager pluginManager;
+
+ @Parameter(name = "asciidoctor-maven-plugin-version", defaultValue = "2.1.0")
+ private String asciidoctorMavenPluginVersion;
+
+ @Parameter(name = "asciidoctorj-pdf-version", defaultValue = "1.5.4")
+ private String asciidoctorjPdfVersion;
+
+ @Parameter(name = "jruby-version", defaultValue = "9.2.9.0")
+ private String jrubyVersion;
+
+ @Parameter(name = "asciidoctorj-version", defaultValue = "2.4.3")
+ private String asciidoctorjVersion;
+
+ @Parameter(name = "kroki-server-url", defaultValue = "${kroki.server.url}")
+ private String krokiServerUrl;
+
+ @Override
+ public void execute() throws MojoExecutionException, MojoFailureException {
+ executeMojo(
+ plugin(
+ groupId("org.asciidoctor"),
+ artifactId("asciidoctor-maven-plugin"),
+ version(asciidoctorMavenPluginVersion),
+ dependencies(
+ dependency("org.asciidoctor", "asciidoctorj-pdf", asciidoctorjPdfVersion),
+ dependency("org.jruby", "jruby-complete", jrubyVersion),
+ dependency("org.asciidoctor", "asciidoctorj", asciidoctorjVersion)
+ )
+ ),
+ goal("process-asciidoc"),
+ configuration(
+ // TODO conditionalize that invocation : add all gems dependencies here
+ element(name("requires"),
+ element(name("require"), "asciidoctor-kroki")),
+ element(name("gemPath"), "${project.build.directory}/gems"),
+ element(name("attributes"),
+ element(name("allow-uri-read")), // allow to include distant content in the created document
+ element(name("kroki-server-url"), krokiServerUrl),
+
+ element(name("structurizrdir"), "${agile.architecture.output.diagrams}"),
+ element(name("imagesdir"), "./images"),
+ element(name("toc"), "left"), // put the table of content on the left side of the window
+ element(name("icons"), "font"), // allow to use icons from "fonticones"
+ element(name("sectanchors"), "true"), // sections behave like anchors/links to move around the document
+ element(name("idseparator"), "-"), // put a separator between identifiers pieces
+ element(name("hideBugReport"), "${asciidoc.documents.hide.bug.report}"), // add link to allow users to report some bugs
+
+ element(name("sectnums"), "true"), // display section number in the summary
+ element(name("revnumber"), "${project.version}"), // add project version in the footer
+ element(name("revdate"), "${maven.build.timestamp}"), // add the date in the footer
+
+ element(name("project-group-id"), "${project.groupId}"), // catch the groupId defined in the pom.xml file
+ element(name("project-artifact-id"), "${project.artifactId}"), // catch the artifactId defined in the pom.xml file
+ element(name("project-name"), "${project.name}"), // catch the project name defined in the pom.xml file
+ element(name("project-version"), "${project.version}"), // catch the project version defined in the pom.xml file
+ element(name("project-build-timestamp"), "${maven.build.timestamp}"), // catch the timestamp defined when maven build
+ element(name("project-pom-path"), "../../../pom.xml"), // catch pom.xml file path
+ element(name("project-issues-on-github"), "${issues.url}"), // catch the issue url defined in the pom.xml file
+ element(name("organization"), "${project.organization.name}"), // catch the organization name defined in the pom.xml file
+ element(name("enhancements-dir"), "${agile.architecture.output.enhancements}") // catch the path to the enhancements directory defined in the pom.xml file
+ ),
+ element(name("outputDirectory"), "${project.build.directory}/foo") // define the path where the html files will get created
+ ),
+ executionEnvironment(
+ mavenProject,
+ mavenSession,
+ pluginManager
+ )
+ );
+ }
+}