Merge pull request #666 from OpenSimulationInterface/antora/base-antora-setup

Build: Create base Antora setup

Author: philipwindecker

.antora/antora.yml

@@ -0,0 +1,10 @@
+# Component name (without spaces!). All content repositories with the same component name are merged in Antora.
+name: asamosi
+version:
+  # Update version number accordingly. This is the version for the main branch
+  main: 'current'
+  v(*)-antora: V$1
+  v(*): V$1
+  V(*): V$1
+  # Update version number accordingly. This is the version for any other activated branch (branch must be added in the generator site.yml!). Schema = 0.0.x-<branch-name> (only works for branches starting with "feature/")
+  (*): 'V3.6.0-$1'

.antora/modules/gen/doxynav.adoc

@@ -0,0 +1 @@
+../../../doc/images

.antora/modules/interface/images

@@ -0,0 +1,22 @@
+[preface]
+* xref:00_preface/00_foreword.adoc[]
+[preface]
+* xref:00_preface/01_introduction.adoc[]
+* xref:01_scope/01_scope.adoc[]
+* xref:02_normative_references/01_normative_references.adoc[]
+* xref:03_terms_and_definitions/01_terms_and_definitions.adoc[]
+* xref:04_abbreviations/01_abbreviations.adoc[]
+* xref:05_backward_compatibility/01_backward_compatibility.adoc[]
+
+[appendix]
+* xref:xx_annexes/REPLACE_ME.adoc[]
+[bibliography]
+* xref:bibliography.adoc[]
+
+:sectnums!:
+* xref:list_of_figures.adoc[]
+
+:sectnums!:
+* xref:list_of_tables.adoc[]
+
+// TODO Replace with generator

.antora/modules/interface/nav.adoc

@@ -0,0 +1 @@
+../../../doc

.antora/modules/interface/pages

@@ -11,8 +11,8 @@ Is this a bug fix or a feature? Does it break any existing functionality or forc
 How has it been tested?
 
 #### Take this checklist as orientation for yourself, if this PR is ready for the Change Control Board:
-- [ ] My suggestion follows the [style and contributors guidelines](https://opensimulationinterface.github.io/osi-documentation/open-simulation-interface/doc/howtocontribute.html).
-- [ ] I have taken care about the [documentation](https://opensimulationinterface.github.io/osi-documentation/open-simulation-interface/doc/commenting.html).
+- [ ] My suggestion follows the [style and contributors guidelines](https://opensimulationinterface.github.io/osi-antora-generator/asamosi/latest/specification/contributing/start_contributing.html).
+- [ ] I have taken care about the [message documentation](https://opensimulationinterface.github.io/osi-antora-generator/asamosi/latest/specification/contributing/commenting_messages.html) and the [fields and enums documentation](https://opensimulationinterface.github.io/osi-antora-generator/asamosi/latest/specification/contributing/commenting_fields_enums.html).
 - [ ] I have done the [DCO signoff](https://opensimulationinterface.github.io/osi-documentation/open-simulation-interface/doc/howtocontribute.html#developer-certification-of-origin-dco).
 - [ ] My changes generate no errors when passing CI tests. 
 - [ ] I have successfully implemented and tested my fix/feature locally.

.github/pull_request_template.md

@@ -9,6 +9,8 @@ As the complexity of automated driving functions rapidly increases, the requirem
 
 For more information on OSI see the [official documentation](https://opensimulationinterface.github.io/osi-documentation/) or the [official reference documentation](https://opensimulationinterface.github.io/open-simulation-interface/) for defined protobuf messages.
 
+<!-- TODO: Update with new Antora hosting -->
+
 [1] Hanke, T., Hirsenkorn, N., van-Driesten, C., Garcia-Ramos, P., Schiementz, M., Schneider, S. & Biebl, E. (2017, February 03). *A generic interface for the environment perception of automated driving functions in virtual scenarios.* Retrieved January 25, 2020, from https://www.hot.ei.tum.de/forschung/automotive-veroeffentlichungen/
 
 ## Usage

README.md

@@ -0,0 +1,56 @@
+
+// This file contains AsciiDoc attributes that shall be used in every AsciiDoc file.
+// NOTE: Its content is only applied for Asciidoctor!
+// If the same attribute is defined in the antora.yml (without @), the antora.yml definition takes precedence for Antora.
+
+ifndef::root-path[:root-path: ./]
+
+:partials-path: {root-path}../_additional_content
+:asciidoc-resources: ../asciidoc-resources
+:appendix-caption: Annex
+:page-feedbackurl: https://github.com/OpenSimulationInterface/open-simulation-interface/issues/new
+
+// ifndef::use-antora-rules,include-only-once[]
+ifndef::include-only-once[]
+:GLO_VAR_STA_ASAM_OpenCRG: ASAM OpenCRG
+:glo_var_sta_asam_opencrg: {GLO_VAR_STA_ASAM_OpenCRG}
+:GLO_VAR_STA_ASAM_OpenDRIVE: ASAM OpenDRIVE
+:GLO_VAR_STA_ASAM_OpenLABEL: ASAM OpenLABEL
+:GLO_VAR_STA_ASAM_OpenODD: ASAM OpenODD
+:GLO_VAR_STA_ASAM_OSI: ASAM OSI®
+:GLO_VAR_STA_ASAM_OpenSCENARIO: ASAM OpenSCENARIO
+:GLO_VAR_STA_ASAM_OpenXOntology: ASAM OpenXOntology
+:GLO_VAR_STA_BSI_PAS_1883: BSI PAS 1883
+:revnumber: --localbuild--
+:revdate: {docdate}
+:bibtex-file: ./content/general_docs/bibliography.bib
+// Replace PLACEHOLDER with the name of your standard, e.g. OpenDRIVE
+:THIS_STANDARD: {GLO_VAR_STA_ASAM_OSI}
+:asam-terminology: https://code.asam.net/common/asam-terminology/-/raw/main/terms_and_definitions_opendrive.adoc
+:imagesdir: {root-path}/images
+:include-only-once: true
+:topicdir: topics
+:reusedir: reuse
+:toclevels: 3
+:xrefstyle: full
+:images_open_simulation_interface: {imagesdir}
+// :images_osi-sensor-model-packaging: ./osi-sensor-model-packaging/doc/images
+:doc_open_simulation_interface: ../../open-simulation-interface/doc/
+:doc_osi-sensor-model-packaging: ../../osi-sensor-model-packaging/doc/
+// Since a document spanning multiple repos is rendered here, the pathing regarding images is a bit involved.
+// We create a variable for every repo that is included. It point to the repo in question.
+// If the subrepo is rendered seperatly, then the variable is set to just "./images" with ifdef.
+// Please note that this variable has to used in all image includes. Includes here have to use "image::./images..."
+// :images_osi_sensor_model_packaging: ./osi-sensor-model-packaging/doc/images  // example
+:imagesoutdir: ./images/generated_images
+
+endif::[]
+
+ifndef::use-antora-rules[]
+include::{asciidoc-resources}/preamble.adoc[]
+endif::[]
+
+ifdef::env-gitlab[]
+:relfilesuffix: .adoc
+endif::[]
+

doc/_config.adoc

@@ -1,3 +1,7 @@
+ifndef::include-only-once[]
+:root-path: ../
+include::{root-path}_config.adoc[]
+endif::[]
 = Overview of OSI architecture
 
 OSI contains an object-based environment description that uses the message format of the https://github.com/protocolbuffers/protobuf/wiki[Protocol Buffer] library.
@@ -7,6 +11,7 @@ Top-level messages define the `GroundTruth` interface, the `SensorData` interfac
 
 The following figure shows the interfaces and models involved in modeling a sensor.
 
+[#fig-open-simulation-interface-overview]
 .Open Simulation Interface overview
 image::{images_open_simulation_interface}/osi-context.png[1100]
 
@@ -16,12 +21,14 @@ The `TrafficCommand` interface makes it possible to send commands to traffic par
 The `TrafficUpdate` interface makes it possible to receive the updated state from traffic participant models.
 The following figure shows the interfaces of a generic traffic participant.
 
+[#fig-interface-traffic-participant]
 .Interface of a traffic participant
 image::{images_open_simulation_interface}/osi-traffic-participant-principle.png[1100]
 
 Traffic participant models may use other OSI interfaces internally, for example, to model autonomous vehicles.
 The following figure shows a more advanced use case for traffic participants.
 
+[#fig-traffic-participant-sensor-models]
 .Traffic participant with sensor models, AD function, and dynamic model
 image::{images_open_simulation_interface}/osi-traffic-participant-advanced.png[1100]
 

doc/architecture/architecture_overview.adoc

@@ -1,3 +1,7 @@
+ifndef::include-only-once[]
+:root-path: ../
+include::{root-path}_config.adoc[]
+endif::[]
 = Data layer
 
 The OSI data layer is defined in the message specifications using the ProtoBuf IDL cite:[protobuf].