Update Developer Guides (#3088)

3 files changed, 0 insertions, 327 deletions

diff --git a/mkdocs/src/doc/docs/developer_guide/architecture/extension_points/base_extensions.md b/mkdocs/src/doc/docs/developer_guide/architecture/extension_points/base_extensions.md
deleted file mode 100644
index 16a52fab..00000000
--- a/mkdocs/src/doc/docs/developer_guide/architecture/extension_points/base_extensions.md
+++ /dev/null
@@ -1,13 +0,0 @@
-# Base extensions
-
-`DokkaBase` class is a base plugin which defines a number of default implementations for `CoreExtensions` as well as
-declares its own, more high-level extension points to be used from other plugins and output formats.
-
-It's very convenient to use extension points and defaults defined in `DokkaBase` if you have an idea for a simple
-plugin that only needs to provide a few extensions or change a single extension point and have everything else be the
-default.
-
-`DokkaBase` is used extensively for Dokka's own output formats such as `HTML`, `Markdown`, `Mathjax` and others.
-
-You can learn how to add/use/override/configure extensions and extension points in
-[Introduction to Extensions](introduction.md), all the information is applicable to `DokkaBase` plugin as well.
diff --git a/mkdocs/src/doc/docs/developer_guide/architecture/extension_points/core_extensions.md b/mkdocs/src/doc/docs/developer_guide/architecture/extension_points/core_extensions.md
deleted file mode 100644
index 77ebc15e..00000000
--- a/mkdocs/src/doc/docs/developer_guide/architecture/extension_points/core_extensions.md
+++ /dev/null
@@ -1,151 +0,0 @@
-# Core extension points
-
-Core extension points represent the main stages of generating documentation. 
-
-These extension points are plugin and output format independent, meaning it's the very core functionality and as
-low-level as can get. For higher-level extension functions that can be used in different output formats, have a look at
-[Base extensions](base_extensions.md) defined in `DokkaBase`.
-
-You can find all core extensions in `CoreExtensions` class:
-```kotlin
-object CoreExtensions {
-    val preGenerationCheck by coreExtensionPoint<PreGenerationChecker>()
-    val generation by coreExtensionPoint<Generation>()
-    val sourceToDocumentableTranslator by coreExtensionPoint<SourceToDocumentableTranslator>()
-    val documentableMerger by coreExtensionPoint<DocumentableMerger>()
-    val documentableTransformer by coreExtensionPoint<DocumentableTransformer>()
-    val documentableToPageTranslator by coreExtensionPoint<DocumentableToPageTranslator>()
-    val pageTransformer by coreExtensionPoint<PageTransformer>()
-    val renderer by coreExtensionPoint<Renderer>()
-    val postActions by coreExtensionPoint<PostAction>()
-}
-```
-
-On this page we'll go over each extension point individually.
-
-## PreGenerationChecker
-
-`PreGenerationChecker` can be used to run some checks and constraints. 
-
-For instance, `Javadoc` plugin does not support generating documentation for multi-platform projects, so it uses
-`PreGenerationChecker` to check for multi-platform
-[source sets](https://kotlinlang.org/docs/multiplatform-discover-project.html#source-sets) and fails if it finds any.
-
-## Generation
-
-`Generation` is responsible for generating documentation as a whole, utilizing other extension points where applicable.
-
-There are two implementations at the moment:
-
-* `AllModulesPageGeneration` - generates multimodule documentation, for instance when `dokkaHtmlMultiModule` task is
-  invoked.
-* `SingleModuleGeneration` - generates documentation for a single module, for instance when `dokkaHtml` task is invoked
-
-### AllModulesPageGeneration
-
-`AllModulesPageGeneration` utilizes output generated by `SingleModuleGeneration`. Under the hood it just collects all
-pages generated for individual modules and assembles everything together, creating navigation pages between the
-modules and so on.
-
-### SingleModuleGeneration stages
-
-When developing a feature or a plugin, it's more convenient to think that you are generating documentation for single
-module projects, believing that Dokka will somehow take care of the rest in multimodule environment.
-
-`SingleModuleGeneration` is at heart of generating documentation and utilizes other core extension points, so
-it's worth going over its stages. 
-
-Below you can see the transformations of [Dokka's models](../architecture_overview.md#overview-of-data-model) and 
-extension interfaces responsible for each one. Notice how `Documentables` and `Pages` are transformed multiple times.
-
-```mermaid
-flowchart TD
-    Input -- SourceToDocumentableTranslator --> doc1[Documentables]
-    subgraph documentables [ ]
-    doc1 -- PreMergeDocumentableTransformer --> doc2[Documentables]
-    doc2 -- DocumentableMerger --> doc3[Documentables]
-    doc3 -- DocumentableTransformer --> doc4[Documentables]
-    end
-    doc4 -- DocumentableToPageTranslator --> page1[Pages]
-    subgraph ide2 [ ]
-    page1 -- PageTransformer --> page2[Pages]
-    end
-    page2 -- Renderer --> Output
-```
-
-#### SourceToDocumentableTranslator
-
-`SourceToDocumentableTranslator` translates sources into documentable model. 
-
-`Kotlin` and `Java` sources are supported by default, but you can analyze any language as long as you can map
-it to the [Documentable](../data_model/documentables.md) model.
-
-For reference, see
-
-* `DefaultDescriptorToDocumentableTranslator` for `Kotlin` sources translation
-* `DefaultPsiToDocumentableTranslator` for `Java` sources translation
-
-#### PreMergeDocumentableTransformer
-
-This extension point actually comes from `DokkaBase` and is not a core extension point, but it's used in
-`SingleModuleGeneration` nonetheless. If you are implementing your own plugin without relying on `DokkaBase`,
-you can either introduce a similar extension point or rely on [DocumentableTransformer](#documentabletransformer) which
-will be discussed below.
-
-`PreMergeDocumentableTransformer` allows applying any transformation to 
-[Documentables model](../data_model/documentables.md) before different 
-[source sets](https://kotlinlang.org/docs/multiplatform-discover-project.html#source-sets) are merged. 
-
-Useful if you want to filter/map existing documentables. For instance, if you want to exclude members annotated with
-`@Internal`, you most likely need an implementation of `PreMergeDocumentableTransformer`.
-
-For simple condition-based filtering of documentables consider extending 
-`SuppressedByConditionDocumentableFilterTransformer` - it implements `PreMergeDocumentableTransformer` and only
-requires one function to be overridden. The rest is taken care of.
-
-#### DocumentableMerger
-
-`DocumentableMerger` merges all `DModule` instances into one. Only one extension is expected of this type.
-
-#### DocumentableTransformer
-
-`DocumentableTransformer` performs the same function as `PreMergeDocumentableTransformer`, but after merging source
-sets.
-
-Notable example is `InheritorsExtractorTransformer`, it extracts inherited classes data across 
-[source sets](https://kotlinlang.org/docs/multiplatform-discover-project.html#source-sets) and creates an inheritance
-map.
-
-#### DocumentableToPageTranslator
-
-`DocumentableToPageTranslator` is responsible for creating pages and their content. See 
-[Page/Content model](../data_model/page_content.md) section for more information and examples.
-
-Different output formats can either use the same page structure or define their own in case it needs to be different.
-
-Only a single extension of this type is expected to be registered. 
-
-#### PageTransformer
-
-`PageTransformer` is useful if you need to add/remove/modify generated pages or their content.
-
-Plugins like `mathjax` can add `.js` scripts to pages using this extension point. 
-
-If you want all overloaded functions to be rendered on the same page (instead of separate ones),
-you can also use `PageTransformer` to delete excessive pages and combine them into a new single one.
-
-#### Renderer
-
-`Renderer` - defines rules on what to do with pages and their content, which files to create and how to display
-it properly. 
-
-Output format implementations should use `Renderer` extension point. Notable examples are `HtmlRenderer`
-and `CommonmarkRenderer`.
-
-## PostAction
-
-`PostAction` is useful for when you want to run some actions after the documentation has been generated - for instance
-if you want to move some files around.
-
-[Versioning plugin](https://github.com/Kotlin/dokka/tree/master/plugins/versioning) utilizes `PostAction` in order to move
-generated documentation to versioned folders.
diff --git a/mkdocs/src/doc/docs/developer_guide/architecture/extension_points/introduction.md b/mkdocs/src/doc/docs/developer_guide/architecture/extension_points/introduction.md
deleted file mode 100644
index 877d14e9..00000000
--- a/mkdocs/src/doc/docs/developer_guide/architecture/extension_points/introduction.md
+++ /dev/null
@@ -1,163 +0,0 @@
-# Introduction to extension points
-
-In this section you can learn how to create new extension points, how to use and configure existing ones and
-how to query for extensions when generating documentation.
-
-## Declaring extension points
-
-If you are writing a plugin, you can create your own extension point that other developers (or you) can use later on
-in some other part of code.
-
-```kotlin
-class MyPlugin : DokkaPlugin() {
-    val sampleExtensionPoint by extensionPoint<SampleExtensionPointInterface>()
-}
-
-interface SampleExtensionPointInterface {
-    fun doSomething(input: Input): List<Output>
-}
-
-class Input
-class Output
-```
-
-Usually you would want to provide some default implementation(s) for your extension point, you can do that
-within the same plugin class by extending an extension point you've just created.
-See [Extending from extension points](#extending-from-extension-points) for examples.
-
-## Extending from extension points
-
-You can use extension points to provide your own implementation(s) in order to customize plugin's behaviour.
-
-You can do that within the same class as the extension point itself:
-
-```kotlin
-open class MyPlugin : DokkaPlugin() {
-    val sampleExtensionPoint by extensionPoint<SampleExtensionPointInterface>()
-
-    val defaultSampleExtension by extending {
-        sampleExtensionPoint with DefaultSampleExtension()
-    }
-}
-
-...
-
-class DefaultSampleExtension : SampleExtensionPointInterface {
-    override fun doSomething(input: Input): List<Output> = listOf()
-}
-```
-
-___
-
-If you want to extend someone else's plugin (including `DokkaBase`), you can use plugin querying API to do that.
-In the example below we will extend `MyPlugin` that was created above with our own implementation of
-`SampleExtensionPointInterface`.
-
-```kotlin
-class MyExtendedPlugin : DokkaPlugin() {
-    val mySampleExtensionImplementation by extending {
-        plugin<MyPlugin>().sampleExtensionPoint with SampleExtensionImpl()
-    }
-}
-
-class SampleExtensionImpl : SampleExtensionPointInterface {
-    override fun doSomething(input: Input): List<Output> = listOf()
-}
-
-```
-
-### Providing
-
-If you need to have access to `DokkaContext` in order to create an extension, you can use `providing` instead. 
-
-```kotlin
-val defaultSampleExtension by extending {
-    sampleExtensionPoint providing { context ->
-        // can use context to query other extensions or get configuration 
-        DefaultSampleExtension() 
-    }
-}
-```
-
-You can read more on what you can do with `context` in [Obtaining extension instance](#obtaining-extension-instance).
-
-### Override
-
-By extending an extension point, you are registering an _additional_ extension. This behaviour is expected for some
-extension points, for instance `Documentable` transformers, since all transformers do their own transformations and all
-of them will be invoked before proceeding.
-
-However, a plugin can expect only a single registered extension for an extension point. In this case, you can `override`
-existing registered extensions:
-
-```kotlin
-class MyExtendedPlugin : DokkaPlugin() {
-    private val myPlugin by lazy { plugin<MyPlugin>() }
-
-    val mySampleExtensionImplementation by extending {
-        (myPlugin.sampleExtensionPoint
-                with SampleExtensionImpl()
-                override myPlugin.defaultSampleExtension)
-    }
-}
-```
-
-This is also useful if you wish to override some extension from `DokkaBase` to disable or alter it.
-
-### Order
-
-Sometimes the order in which extensions are invoked matters. This is something you can control as well using `order`:
-
-```kotlin
-class MyExtendedPlugin : DokkaPlugin() {
-    private val myPlugin by lazy { plugin<MyPlugin>() }
-
-    val mySampleExtensionImplementation by extending {
-        myPlugin.sampleExtensionPoint with SampleExtensionImpl() order {
-            before(myPlugin.firstExtension)
-            after(myPlugin.thirdExtension)
-        }
-    }
-}
-```
-
-### Conditional apply
-
-If you want your extension to be registered only if some condition is `true`, you can use `applyIf`:
-
-```kotlin
-class MyExtendedPlugin : DokkaPlugin() {
-    private val myPlugin by lazy { plugin<MyPlugin>() }
-    
-    val mySampleExtensionImplementation by extending {
-        myPlugin.sampleExtensionPoint with SampleExtensionImpl() applyIf {
-            Random.Default.nextBoolean()
-        }
-    }
-}
-```
-
-## Obtaining extension instance
-
-After an extension point has been [created](#declaring-extension-points) and some extension has been
-[registered](#extending-from-extension-points), you can use `query` and `querySingle` to find all or just a single
-implementation for it.
-
-```kotlin
-class MyExtension(context: DokkaContext) {
-    // returns all registered extensions for this extension point
-    val allSampleExtensions = context.plugin<MyPlugin>().query { sampleExtensionPoint }
-    
-    // will throw an exception if more than one extension is found
-    // use if you expect only a single extension to be registered for this extension point
-    val singleSampleExtensions = context.plugin<MyPlugin>().querySingle { sampleExtensionPoint }
-    
-    fun invoke() {
-        allSampleExtensions.forEach { it.doSomething(Input()) }
-        
-        singleSampleExtensions.doSomething(Input())
-    }
-}
-```
-
-In order to have access to context you can use [providing](#providing) when registering this as an extension.