Re-enable kotlin IDE tests, move images into subfolders (com-lihaoyi#…

…3731)

docs/modules/ROOT/pages/comparisons/gradle.adoc

@@ -190,15 +190,15 @@ and associated test suites, but how do these different modules depend on each ot
 Mill, you can run `./mill visualize __.compile`, and it will show you how the
 `compile` task of each module depends on the others:
 
-image::MockitoCompileGraph.svg[]
+image::comparisons/MockitoCompileGraph.svg[]
 
 Apart from the static dependency graph, another thing of interest may be the performance
 profile and timeline: where the time is spent when you actually compile everything. With
 Mill, when you run a compilation using `./mill -j 10 __.compile`, you automatically get a
 `out/mill-chrome-profile.json` file that you can load into your `chrome://tracing` page and
 visualize where your build is spending time and where the performance bottlenecks are:
 
-image::MockitoCompileProfile.png[]
+image::comparisons/MockitoCompileProfile.png[]
 
 If you want to inspect the tree of third-party dependencies used by any module, the
 built in `ivyDepsTree` command lets you do that easily:

docs/modules/ROOT/pages/comparisons/maven.adoc

@@ -599,15 +599,15 @@ and associated test suites, but how do these different modules depend on each ot
 Mill, you can run `./mill visualize __.compile`, and it will show you how the
 `compile` task of each module depends on the others:
 
-image::NettyCompileGraph.svg[]
+image::comparisons/NettyCompileGraph.svg[]
 
 Apart from the static dependency graph, another thing of interest may be the performance
 profile and timeline: where the time is spent when you actually compile everything. With
 Mill, when you run a compilation using `./mill -j 10 __.compile`, you automatically get a
 `out/mill-chrome-profile.json` file that you can load into your `chrome://tracing` page and
 visualize where your build is spending time and where the performance bottlenecks are:
 
-image::NettyCompileProfile.png[]
+image::comparisons/NettyCompileProfile.png[]
 
 If you want to inspect the tree of third-party dependencies used by any module, the
 built in `ivyDepsTree` command lets you do that easily:

docs/modules/ROOT/pages/comparisons/sbt.adoc

@@ -187,13 +187,13 @@ IDEs like IntelliJ are nominally able to parse and analyze your SBT files, the a
 provide is often not very useful. For example, consider the inspection and jump-to-definition experience
 of looking into an SBT Task:
 
-image::IntellijGatlingSbtTask1.png[]
-image::IntellijGatlingSbtTask2.png[]
+image::comparisons/IntellijGatlingSbtTask1.png[]
+image::comparisons/IntellijGatlingSbtTask2.png[]
 
 Or an SBT plugin:
 
-image::IntellijGatlingSbtPlugin1.png[]
-image::IntellijGatlingSbtPlugin2.png[]
+image::comparisons/IntellijGatlingSbtPlugin1.png[]
+image::comparisons/IntellijGatlingSbtPlugin2.png[]
 
 In general, although your IDE can make sure the name of the task exists, and the type is correct, it
 is unable to pull up any further information about the task: its documentation, its implementation,
@@ -205,22 +205,22 @@ at all: what it does, where it is assigned, etc.
 In comparison, for Mill, IDEs like Intellij are able to provide much more intelligence. e.g. when
 inspecting a task, it is able to pull up the documentation comment:
 
-image::IntellijGatlingMillTask1.png[]
+image::comparisons/IntellijGatlingMillTask1.png[]
 
 It is able to pull up any overridden implementations of task, directly in the editor:
 
-image::IntellijGatlingMillTask2.png[]
+image::comparisons/IntellijGatlingMillTask2.png[]
 
 And you can easily navigate to the overriden implementations to see where they are defined and
 what you are overriding:
 
-image::IntellijGatlingMillTask3.png[]
+image::comparisons/IntellijGatlingMillTask3.png[]
 
 Mill's equivalent of SBT plugins are just Scala traits, and again you can easily pull up their
 documentation in-line in the editor or jump to their full implementation:
 
-image::IntellijGatlingMillPlugin1.png[]
-image::IntellijGatlingMillPlugin2.png[]
+image::comparisons/IntellijGatlingMillPlugin1.png[]
+image::comparisons/IntellijGatlingMillPlugin2.png[]
 
 In general, navigating around your build in Mill is much more straightforward than
 navigating around your build in SBT. All your normal IDE functionality works perfectly:
@@ -237,15 +237,15 @@ and associated test suites, but how do these different modules depend on each ot
 Mill, you can run `./mill visualize __.compile`, and it will show you how the
 `compile` task of each module depends on the others:
 
-image::GatlingCompileGraph.svg[]
+image::comparisons/GatlingCompileGraph.svg[]
 
 Apart from the static dependency graph, another thing of interest may be the performance
 profile and timeline: where the time is spent when you actually compile everything. With
 Mill, when you run a compilation using `./mill -j 10 __.compile`, you automatically get a
 `out/mill-chrome-profile.json` file that you can load into your `chrome://tracing` page and
 visualize where your build is spending time and where the performance bottlenecks are:
 
-image::GatlingCompileProfile.png[]
+image::comparisons/GatlingCompileProfile.png[]
 
 If you want to inspect the tree of third-party dependencies used by any module, the
 built in `ivyDepsTree` command lets you do that easily:

docs/modules/ROOT/pages/kotlinlib/installation-ide.adoc

@@ -1,6 +1,6 @@
 = Installation and IDE Support
 
+:language: Kotlin
+:language-small: kotlin
 
-Kotlin IDE support is work in progress. For details, see the following issue:
-
-* https://github.com/com-lihaoyi/mill/issues/3606
+include::partial$Installation_IDE_Support.adoc[]

docs/modules/ROOT/partials/Installation_IDE_Support.adoc

@@ -95,19 +95,19 @@ containing a Mill `build.mill` file, and IntelliJ will automatically load the
 Mill build. This will provide support both for your application code,
 as well as the code in the `build.mill`:
 
-image::IntellijApp.png[]
+image::basic/IntellijApp.png[]
 
-image::IntellijBuild.png[]
+image::basic/IntellijBuild.png[]
 
 If IntelliJ does not highlight the `.mill` files correctly, you can explicitly enable
 it by adding `*.mill` to the `Scala` file type:
 
-image::IntellijFileTypeConfig.png[]
+image::basic/IntellijFileTypeConfig.png[]
 
 If you make changes to your Mill `build.mill`, you can ask Intellij to load
 those updates by opening the "BSP" tab and clicking the "Refresh" button
 
-image::IntellijRefresh.png[]
+image::basic/IntellijRefresh.png[]
 
 ==== IntelliJ IDEA XML Support
 
@@ -157,14 +157,14 @@ containing a Mill `build.mill` file, and VSCode will ask you to import your
 Mill build. This will provide support both for your application code,
 as well as the code in the `build.mill`:
 
-image::VSCodeApp.png[]
+image::basic/VSCodeApp.png[]
 
-image::VSCodeBuild.png[]
+image::basic/VSCodeBuild.png[]
 
 If you make changes to your Mill `build.sc`, you can ask VSCode to load
 those updates by opening the "BSP" tab and clicking the "Refresh" button
 
-image::VSCodeRefresh.png[]
+image::basic/VSCodeRefresh.png[]
 
 === Debugging IDE issues
 

docs/modules/ROOT/partials/Intro_to_Mill_Footer.adoc

@@ -49,7 +49,7 @@ loaded into the Chrome browser's `chrome://tracing` page for visualization.
 This can make it much easier to analyze your parallel runs to find out what's
 taking the most time:
 
-image::ChromeTracing.png[ChromeTracing.png]
+image::basic/ChromeTracing.png[ChromeTracing.png]
 
 Note that the maximal possible parallelism depends both on the number of cores
 available as well as the task and module structure of your project, as tasks that

example/javalib/module/1-common-config/build.mill

@@ -50,7 +50,7 @@ object `package` extends RootModule with JavaModule {
 > mill visualizePlan run
 */
 //
-// image::VisualizePlanJava.svg[VisualizePlanJava.svg]
+// image::basic/VisualizePlanJava.svg[VisualizePlanJava.svg]
 //
 // (right-click open in new tab to see full sized)
 //

example/kotlinlib/module/1-common-config/build.mill

@@ -53,7 +53,7 @@ object `package` extends RootModule with KotlinModule {
 > mill visualizePlan run
 */
 //
-// image::VisualizePlanJava.svg[VisualizePlanJava.svg]
+// image::basic/VisualizePlanJava.svg[VisualizePlanJava.svg]
 //
 // (right-click open in new tab to see full sized)
 //

example/scalalib/basic/4-builtin-commands/build.mill

@@ -302,7 +302,7 @@ foo.compileClasspath
 //
 // The above command generates the following diagram (right-click open in new tab to see full sized):
 //
-// image::VisualizeJava.svg[VisualizeJava.svg]
+// image::basic/VisualizeJava.svg[VisualizeJava.svg]
 //
 // `visualize` can be very handy for trying to understand the dependency graph of
 // tasks within your Mill build.
@@ -327,7 +327,7 @@ foo.compileClasspath
 //
 // The above command generates the following diagram (right-click open in new tab to see full sized):
 //
-// image::VisualizePlanJava.svg[VisualizePlanJava.svg]
+// image::basic/VisualizePlanJava.svg[VisualizePlanJava.svg]
 //
 //
 // == init

example/scalalib/module/1-common-config/build.mill

@@ -61,7 +61,7 @@ object `package` extends RootModule with ScalaModule {
 > mill visualizePlan run
 */
 //
-// image::VisualizePlanScala.svg[VisualizePlanScala.svg]
+// image::basic/VisualizePlanScala.svg[VisualizePlanScala.svg]
 //
 // (right-click open in new tab to see full sized)
 //