Merge staging-next into staging

12 files changed, 270 insertions, 262 deletions

diff --git a/doc/builders/packages/index.xml b/doc/builders/packages/index.xml
index 3a7ca59505cf..ba59ceb016b6 100644
--- a/doc/builders/packages/index.xml
+++ b/doc/builders/packages/index.xml
@@ -15,11 +15,11 @@
  <xi:include href="linux.xml" />
  <xi:include href="locales.xml" />
  <xi:include href="nginx.xml" />
- <xi:include href="opengl.xml" />
+ <xi:include href="opengl.section.xml" />
  <xi:include href="shell-helpers.xml" />
  <xi:include href="steam.xml" />
  <xi:include href="cataclysm-dda.section.xml" />
  <xi:include href="urxvt.xml" />
- <xi:include href="weechat.xml" />
- <xi:include href="xorg.xml" />
+ <xi:include href="weechat.section.xml" />
+ <xi:include href="xorg.section.xml" />
 </chapter>
diff --git a/doc/builders/packages/opengl.section.md b/doc/builders/packages/opengl.section.md
new file mode 100644
index 000000000000..6866bf89221a
--- /dev/null
+++ b/doc/builders/packages/opengl.section.md
@@ -0,0 +1,15 @@
+# OpenGL {#sec-opengl}
+
+OpenGL support varies depending on which hardware is used and which drivers are available and loaded.
+
+Broadly, we support both GL vendors: Mesa and NVIDIA.
+
+## NixOS Desktop
+
+The NixOS desktop or other non-headless configurations are the primary target for OpenGL libraries and applications. The current solution for discovering which drivers are available is based on [libglvnd](https://gitlab.freedesktop.org/glvnd/libglvnd). `libglvnd` performs "vendor-neutral dispatch", trying a variety of techniques to find the system's GL implementation. In practice, this will be either via standard GLX for X11 users or EGL for Wayland users, and supporting either NVIDIA or Mesa extensions.
+
+## Nix on GNU/Linux
+
+If you are using a non-NixOS GNU/Linux/X11 desktop with free software video drivers, consider launching OpenGL-dependent programs from Nixpkgs with Nixpkgs versions of `libglvnd` and `mesa.drivers` in `LD_LIBRARY_PATH`. For Mesa drivers, the Linux kernel version doesn't have to match nixpkgs.
+
+For proprietary video drivers you might have luck with also adding the corresponding video driver package.
diff --git a/doc/builders/packages/opengl.xml b/doc/builders/packages/opengl.xml
deleted file mode 100644
index dfd64b188586..000000000000
--- a/doc/builders/packages/opengl.xml
+++ /dev/null
@@ -1,9 +0,0 @@
-<section xmlns="http://docbook.org/ns/docbook"
-         xmlns:xlink="http://www.w3.org/1999/xlink"
-         xml:id="sec-opengl">
- <title>OpenGL</title>
-
- <para>
-  Packages that use OpenGL have NixOS desktop as their primary target. The current solution for loading the GPU-specific drivers is based on <literal>libglvnd</literal> and looks for the driver implementation in <literal>LD_LIBRARY_PATH</literal>. If you are using a non-NixOS GNU/Linux/X11 desktop with free software video drivers, consider launching OpenGL-dependent programs from Nixpkgs with Nixpkgs versions of <literal>libglvnd</literal> and <literal>mesa.drivers</literal> in <literal>LD_LIBRARY_PATH</literal>. For proprietary video drivers you might have luck with also adding the corresponding video driver package.
- </para>
-</section>
diff --git a/doc/builders/packages/weechat.section.md b/doc/builders/packages/weechat.section.md
new file mode 100644
index 000000000000..1d99b00e6323
--- /dev/null
+++ b/doc/builders/packages/weechat.section.md
@@ -0,0 +1,85 @@
+# Weechat {#sec-weechat}
+
+Weechat can be configured to include your choice of plugins, reducing its closure size from the default configuration which includes all available plugins. To make use of this functionality, install an expression that overrides its configuration such as
+
+```nix
+weechat.override {configure = {availablePlugins, ...}: {
+    plugins = with availablePlugins; [ python perl ];
+  }
+}
+```
+
+If the `configure` function returns an attrset without the `plugins` attribute, `availablePlugins` will be used automatically.
+
+The plugins currently available are `python`, `perl`, `ruby`, `guile`, `tcl` and `lua`.
+
+The python and perl plugins allows the addition of extra libraries. For instance, the `inotify.py` script in `weechat-scripts` requires D-Bus or libnotify, and the `fish.py` script requires `pycrypto`. To use these scripts, use the plugin's `withPackages` attribute:
+
+```nix
+weechat.override { configure = {availablePlugins, ...}: {
+    plugins = with availablePlugins; [
+            (python.withPackages (ps: with ps; [ pycrypto python-dbus ]))
+        ];
+    };
+}
+```
+
+In order to also keep all default plugins installed, it is possible to use the following method:
+
+```nix
+weechat.override { configure = { availablePlugins, ... }: {
+  plugins = builtins.attrValues (availablePlugins // {
+    python = availablePlugins.python.withPackages (ps: with ps; [ pycrypto python-dbus ]);
+  });
+}; }
+```
+
+WeeChat allows to set defaults on startup using the `--run-command`. The `configure` method can be used to pass commands to the program:
+
+```nix
+weechat.override {
+  configure = { availablePlugins, ... }: {
+    init = ''
+      /set foo bar
+      /server add freenode chat.freenode.org
+    '';
+  };
+}
+```
+
+Further values can be added to the list of commands when running `weechat --run-command "your-commands"`.
+
+Additionally it's possible to specify scripts to be loaded when starting `weechat`. These will be loaded before the commands from `init`:
+
+```nix
+weechat.override {
+  configure = { availablePlugins, ... }: {
+    scripts = with pkgs.weechatScripts; [
+      weechat-xmpp weechat-matrix-bridge wee-slack
+    ];
+    init = ''
+      /set plugins.var.python.jabber.key "val"
+    '':
+  };
+}
+```
+
+In `nixpkgs` there's a subpackage which contains derivations for WeeChat scripts. Such derivations expect a `passthru.scripts` attribute which contains a list of all scripts inside the store path. Furthermore all scripts have to live in `$out/share`. An exemplary derivation looks like this:
+
+```nix
+{ stdenv, fetchurl }:
+
+stdenv.mkDerivation {
+  name = "exemplary-weechat-script";
+  src = fetchurl {
+    url = "https://scripts.tld/your-scripts.tar.gz";
+    sha256 = "...";
+  };
+  passthru.scripts = [ "foo.py" "bar.lua" ];
+  installPhase = ''
+    mkdir $out/share
+    cp foo.py $out/share
+    cp bar.lua $out/share
+  '';
+}
+```
diff --git a/doc/builders/packages/weechat.xml b/doc/builders/packages/weechat.xml
deleted file mode 100644
index a110d3f491c7..000000000000
--- a/doc/builders/packages/weechat.xml
+++ /dev/null
@@ -1,85 +0,0 @@
-<section xmlns="http://docbook.org/ns/docbook"
-         xmlns:xlink="http://www.w3.org/1999/xlink"
-         xml:id="sec-weechat">
- <title>Weechat</title>
-
- <para>
-  Weechat can be configured to include your choice of plugins, reducing its closure size from the default configuration which includes all available plugins. To make use of this functionality, install an expression that overrides its configuration such as
-<programlisting>weechat.override {configure = {availablePlugins, ...}: {
-    plugins = with availablePlugins; [ python perl ];
-  }
-}</programlisting>
-  If the <literal>configure</literal> function returns an attrset without the <literal>plugins</literal> attribute, <literal>availablePlugins</literal> will be used automatically.
- </para>
-
- <para>
-  The plugins currently available are <literal>python</literal>, <literal>perl</literal>, <literal>ruby</literal>, <literal>guile</literal>, <literal>tcl</literal> and <literal>lua</literal>.
- </para>
-
- <para>
-  The python and perl plugins allows the addition of extra libraries. For instance, the <literal>inotify.py</literal> script in weechat-scripts requires D-Bus or libnotify, and the <literal>fish.py</literal> script requires pycrypto. To use these scripts, use the plugin's <literal>withPackages</literal> attribute:
-<programlisting>weechat.override { configure = {availablePlugins, ...}: {
-    plugins = with availablePlugins; [
-            (python.withPackages (ps: with ps; [ pycrypto python-dbus ]))
-        ];
-    };
-}
-</programlisting>
- </para>
-
- <para>
-  In order to also keep all default plugins installed, it is possible to use the following method:
-<programlisting>weechat.override { configure = { availablePlugins, ... }: {
-  plugins = builtins.attrValues (availablePlugins // {
-    python = availablePlugins.python.withPackages (ps: with ps; [ pycrypto python-dbus ]);
-  });
-}; }
-</programlisting>
- </para>
-
- <para>
-  WeeChat allows to set defaults on startup using the <literal>--run-command</literal>. The <literal>configure</literal> method can be used to pass commands to the program:
-<programlisting>weechat.override {
-  configure = { availablePlugins, ... }: {
-    init = ''
-      /set foo bar
-      /server add freenode chat.freenode.org
-    '';
-  };
-}</programlisting>
-  Further values can be added to the list of commands when running <literal>weechat --run-command "your-commands"</literal>.
- </para>
-
- <para>
-  Additionally it's possible to specify scripts to be loaded when starting <literal>weechat</literal>. These will be loaded before the commands from <literal>init</literal>:
-<programlisting>weechat.override {
-  configure = { availablePlugins, ... }: {
-    scripts = with pkgs.weechatScripts; [
-      weechat-xmpp weechat-matrix-bridge wee-slack
-    ];
-    init = ''
-      /set plugins.var.python.jabber.key "val"
-    '':
-  };
-}</programlisting>
- </para>
-
- <para>
-  In <literal>nixpkgs</literal> there's a subpackage which contains derivations for WeeChat scripts. Such derivations expect a <literal>passthru.scripts</literal> attribute which contains a list of all scripts inside the store path. Furthermore all scripts have to live in <literal>$out/share</literal>. An exemplary derivation looks like this:
-<programlisting>{ stdenv, fetchurl }:
-
-stdenv.mkDerivation {
-  name = "exemplary-weechat-script";
-  src = fetchurl {
-    url = "https://scripts.tld/your-scripts.tar.gz";
-    sha256 = "...";
-  };
-  passthru.scripts = [ "foo.py" "bar.lua" ];
-  installPhase = ''
-    mkdir $out/share
-    cp foo.py $out/share
-    cp bar.lua $out/share
-  '';
-}</programlisting>
- </para>
-</section>
diff --git a/doc/builders/packages/xorg.section.md b/doc/builders/packages/xorg.section.md
new file mode 100644
index 000000000000..be220a25404a
--- /dev/null
+++ b/doc/builders/packages/xorg.section.md
@@ -0,0 +1,34 @@
+# X.org {#sec-xorg}
+
+The Nix expressions for the X.org packages reside in `pkgs/servers/x11/xorg/default.nix`. This file is automatically generated from lists of tarballs in an X.org release. As such it should not be modified directly; rather, you should modify the lists, the generator script or the file `pkgs/servers/x11/xorg/overrides.nix`, in which you can override or add to the derivations produced by the generator.
+
+## Katamari Tarballs
+
+X.org upstream releases used to include [katamari](https://en.wiktionary.org/wiki/%E3%81%8B%E3%81%9F%E3%81%BE%E3%82%8A) releases, which included a holistic recommended version for each tarball, up until 7.7. To create a list of tarballs in a katamari release:
+
+```ShellSession
+export release="X11R7.7"
+export url="mirror://xorg/$release/src/everything/"
+cat $(PRINT_PATH=1 nix-prefetch-url $url | tail -n 1) \
+  | perl -e 'while (<>) { if (/(href|HREF)="([^"]*.bz2)"/) { print "$ENV{'url'}$2\n"; }; }' \
+  | sort > "tarballs-$release.list"
+```
+
+## Individual Tarballs
+
+The upstream release process for [X11R7.8](https://x.org/wiki/Releases/7.8/) does not include a planned katamari. Instead, each component of X.org is released as its own tarball. We maintain `pkgs/servers/x11/xorg/tarballs.list` as a list of tarballs for each individual package. This list includes X.org core libraries and protocol descriptions, extra newer X11 interface libraries, like `xorg.libxcb`, and classic utilities which are largely unused but still available if needed, like `xorg.imake`.
+
+## Generating Nix Expressions
+
+The generator is invoked as follows:
+
+```ShellSession
+cd pkgs/servers/x11/xorg
+<tarballs.list perl ./generate-expr-from-tarballs.pl
+```
+
+For each of the tarballs in the `.list` files, the script downloads it, unpacks it, and searches its `configure.ac` and `*.pc.in` files for dependencies. This information is used to generate `default.nix`. The generator caches downloaded tarballs between runs. Pay close attention to the `NOT FOUND: $NAME` messages at the end of the run, since they may indicate missing dependencies. (Some might be optional dependencies, however.)
+
+## Overriding the Generator
+
+If the expression for a package requires derivation attributes that the generator cannot figure out automatically (say, `patches` or a `postInstall` hook), you should modify `pkgs/servers/x11/xorg/overrides.nix`.
diff --git a/doc/builders/packages/xorg.xml b/doc/builders/packages/xorg.xml
deleted file mode 100644
index ebf4930cc097..000000000000
--- a/doc/builders/packages/xorg.xml
+++ /dev/null
@@ -1,34 +0,0 @@
-<section xmlns="http://docbook.org/ns/docbook"
-         xmlns:xlink="http://www.w3.org/1999/xlink"
-         xml:id="sec-xorg">
- <title>X.org</title>
-
- <para>
-  The Nix expressions for the X.org packages reside in <filename>pkgs/servers/x11/xorg/default.nix</filename>. This file is automatically generated from lists of tarballs in an X.org release. As such it should not be modified directly; rather, you should modify the lists, the generator script or the file <filename>pkgs/servers/x11/xorg/overrides.nix</filename>, in which you can override or add to the derivations produced by the generator.
- </para>
-
- <para>
-  The generator is invoked as follows:
-<screen>
-<prompt>$ </prompt>cd pkgs/servers/x11/xorg
-<prompt>$ </prompt>cat tarballs-7.5.list extra.list old.list \
-  | perl ./generate-expr-from-tarballs.pl
-</screen>
-  For each of the tarballs in the <filename>.list</filename> files, the script downloads it, unpacks it, and searches its <filename>configure.ac</filename> and <filename>*.pc.in</filename> files for dependencies. This information is used to generate <filename>default.nix</filename>. The generator caches downloaded tarballs between runs. Pay close attention to the <literal>NOT FOUND: <replaceable>name</replaceable></literal> messages at the end of the run, since they may indicate missing dependencies. (Some might be optional dependencies, however.)
- </para>
-
- <para>
-  A file like <filename>tarballs-7.5.list</filename> contains all tarballs in a X.org release. It can be generated like this:
-<screen>
-<prompt>$ </prompt>export i="mirror://xorg/X11R7.4/src/everything/"
-<prompt>$ </prompt>cat $(PRINT_PATH=1 nix-prefetch-url $i | tail -n 1) \
-  | perl -e 'while (&lt;>) { if (/(href|HREF)="([^"]*.bz2)"/) { print "$ENV{'i'}$2\n"; }; }' \
-  | sort > tarballs-7.4.list
-</screen>
-  <filename>extra.list</filename> contains libraries that aren’t part of X.org proper, but are closely related to it, such as <literal>libxcb</literal>. <filename>old.list</filename> contains some packages that were removed from X.org, but are still needed by some people or by other packages (such as <varname>imake</varname>).
- </para>
-
- <para>
-  If the expression for a package requires derivation attributes that the generator cannot figure out automatically (say, <varname>patches</varname> or a <varname>postInstall</varname> hook), you should modify <filename>pkgs/servers/x11/xorg/overrides.nix</filename>.
- </para>
-</section>
diff --git a/doc/languages-frameworks/coq.section.md b/doc/languages-frameworks/coq.section.md
new file mode 100644
index 000000000000..714e84efc8db
--- /dev/null
+++ b/doc/languages-frameworks/coq.section.md
@@ -0,0 +1,40 @@
+# Coq {#sec-language-coq}
+
+Coq libraries should be installed in `$(out)/lib/coq/${coq.coq-version}/user-contrib/`. Such directories are automatically added to the `$COQPATH` environment variable by the hook defined in the Coq derivation.
+
+Some extensions (plugins) might require OCaml and sometimes other OCaml packages. The `coq.ocamlPackages` attribute can be used to depend on the same package set Coq was built against.
+
+Coq libraries may be compatible with some specific versions of Coq only. The `compatibleCoqVersions` attribute is used to precisely select those versions of Coq that are compatible with this derivation.
+
+Here is a simple package example. It is a pure Coq library, thus it depends on Coq. It builds on the Mathematical Components library, thus it also takes `mathcomp` as `buildInputs`. Its `Makefile` has been generated using `coq_makefile` so we only have to set the `$COQLIB` variable at install time.
+
+```nix
+{ stdenv, fetchFromGitHub, coq, mathcomp }:
+
+stdenv.mkDerivation rec {
+  name = "coq${coq.coq-version}-multinomials-${version}";
+  version = "1.0";
+  src = fetchFromGitHub {
+    owner = "math-comp";
+    repo = "multinomials";
+    rev = version;
+    sha256 = "1qmbxp1h81cy3imh627pznmng0kvv37k4hrwi2faa101s6bcx55m";
+  };
+
+  buildInputs = [ coq ];
+  propagatedBuildInputs = [ mathcomp ];
+
+  installFlags = "COQLIB=$(out)/lib/coq/${coq.coq-version}/";
+
+  meta = {
+    description = "A Coq/SSReflect Library for Monoidal Rings and Multinomials";
+    inherit (src.meta) homepage;
+    license = stdenv.lib.licenses.cecill-b;
+    inherit (coq.meta) platforms;
+  };
+
+  passthru = {
+    compatibleCoqVersions = v: builtins.elem v [ "8.5" "8.6" "8.7" ];
+  };
+}
+```
diff --git a/doc/languages-frameworks/coq.xml b/doc/languages-frameworks/coq.xml
deleted file mode 100644
index 86d9226166f5..000000000000
--- a/doc/languages-frameworks/coq.xml
+++ /dev/null
@@ -1,52 +0,0 @@
-<section xmlns="http://docbook.org/ns/docbook"
-         xmlns:xlink="http://www.w3.org/1999/xlink"
-         xml:id="sec-language-coq">
- <title>Coq</title>
-
- <para>
-  Coq libraries should be installed in <literal>$(out)/lib/coq/${coq.coq-version}/user-contrib/</literal>. Such directories are automatically added to the <literal>$COQPATH</literal> environment variable by the hook defined in the Coq derivation.
- </para>
-
- <para>
-  Some extensions (plugins) might require OCaml and sometimes other OCaml packages. The <literal>coq.ocamlPackages</literal> attribute can be used to depend on the same package set Coq was built against.
- </para>
-
- <para>
-  Coq libraries may be compatible with some specific versions of Coq only. The <literal>compatibleCoqVersions</literal> attribute is used to precisely select those versions of Coq that are compatible with this derivation.
- </para>
-
- <para>
-  Here is a simple package example. It is a pure Coq library, thus it depends on Coq. It builds on the Mathematical Components library, thus it also takes <literal>mathcomp</literal> as <literal>buildInputs</literal>. Its <literal>Makefile</literal> has been generated using <literal>coq_makefile</literal> so we only have to set the <literal>$COQLIB</literal> variable at install time.
- </para>
-
-<programlisting>
-{ stdenv, fetchFromGitHub, coq, mathcomp }:
-
-stdenv.mkDerivation rec {
-  name = "coq${coq.coq-version}-multinomials-${version}";
-  version = "1.0";
-  src = fetchFromGitHub {
-    owner = "math-comp";
-    repo = "multinomials";
-    rev = version;
-    sha256 = "1qmbxp1h81cy3imh627pznmng0kvv37k4hrwi2faa101s6bcx55m";
-  };
-
-  buildInputs = [ coq ];
-  propagatedBuildInputs = [ mathcomp ];
-
-  installFlags = "COQLIB=$(out)/lib/coq/${coq.coq-version}/";
-
-  meta = {
-    description = "A Coq/SSReflect Library for Monoidal Rings and Multinomials";
-    inherit (src.meta) homepage;
-    license = stdenv.lib.licenses.cecill-b;
-    inherit (coq.meta) platforms;
-  };
-
-  passthru = {
-    compatibleCoqVersions = v: builtins.elem v [ "8.5" "8.6" "8.7" ];
-  };
-}
-</programlisting>
-</section>
diff --git a/doc/languages-frameworks/index.xml b/doc/languages-frameworks/index.xml
index 22bc6e1baaaf..c302b67cfd54 100644
--- a/doc/languages-frameworks/index.xml
+++ b/doc/languages-frameworks/index.xml
@@ -9,7 +9,7 @@
  <xi:include href="android.section.xml" />
  <xi:include href="beam.section.xml" />
  <xi:include href="bower.xml" />
- <xi:include href="coq.xml" />
+ <xi:include href="coq.section.xml" />
  <xi:include href="crystal.section.xml" />
  <xi:include href="emscripten.section.xml" />
  <xi:include href="gnome.xml" />
@@ -17,7 +17,7 @@
  <xi:include href="haskell.section.xml" />
  <xi:include href="idris.section.xml" />
  <xi:include href="ios.section.xml" />
- <xi:include href="java.xml" />
+ <xi:include href="java.section.xml" />
  <xi:include href="lua.section.xml" />
  <xi:include href="maven.section.xml" />
  <xi:include href="node.section.xml" />
diff --git a/doc/languages-frameworks/java.section.md b/doc/languages-frameworks/java.section.md
new file mode 100644
index 000000000000..77919d43f748
--- /dev/null
+++ b/doc/languages-frameworks/java.section.md
@@ -0,0 +1,91 @@
+# Java {#sec-language-java}
+
+Ant-based Java packages are typically built from source as follows:
+
+```nix
+stdenv.mkDerivation {
+  name = "...";
+  src = fetchurl { ... };
+
+  nativeBuildInputs = [ jdk ant ];
+
+  buildPhase = "ant";
+}
+```
+
+Note that `jdk` is an alias for the OpenJDK (self-built where available,
+or pre-built via Zulu). Platforms with OpenJDK not (yet) in Nixpkgs
+(`Aarch32`, `Aarch64`) point to the (unfree) `oraclejdk`.
+
+JAR files that are intended to be used by other packages should be
+installed in `$out/share/java`. JDKs have a stdenv setup hook that add
+any JARs in the `share/java` directories of the build inputs to the
+`CLASSPATH` environment variable. For instance, if the package `libfoo`
+installs a JAR named `foo.jar` in its `share/java` directory, and
+another package declares the attribute
+
+```nix
+buildInputs = [ libfoo ];
+nativeBuildInputs = [ jdk ];
+```
+
+then `CLASSPATH` will be set to
+`/nix/store/...-libfoo/share/java/foo.jar`.
+
+Private JARs should be installed in a location like
+`$out/share/package-name`.
+
+If your Java package provides a program, you need to generate a wrapper
+script to run it using a JRE. You can use `makeWrapper` for this:
+
+```nix
+nativeBuildInputs = [ makeWrapper ];
+
+installPhase = ''
+  mkdir -p $out/bin
+  makeWrapper ${jre}/bin/java $out/bin/foo \
+    --add-flags "-cp $out/share/java/foo.jar org.foo.Main"
+'';
+```
+
+Since the introduction of the Java Platform Module System in Java 9,
+Java distributions typically no longer ship with a general-purpose JRE:
+instead, they allow generating a JRE with only the modules required for
+your application(s). Because we can't predict what modules will be
+needed on a general-purpose system, the default jre package is the full
+JDK. When building a minimal system/image, you can override the
+`modules` parameter on `jre_minimal` to build a JRE with only the
+modules relevant for you:
+
+```nix
+let
+  my_jre = pkgs.jre_minimal.override {
+    modules = [
+      # The modules used by 'something' and 'other' combined:
+      "java.base"
+      "java.logging"
+    ];
+  };
+  something = (pkgs.something.override { jre = my_jre; });
+  other = (pkgs.other.override { jre = my_jre; });
+in
+  ...
+```
+
+Note all JDKs passthru `home`, so if your application requires
+environment variables like `JAVA_HOME` being set, that can be done in a
+generic fashion with the `--set` argument of `makeWrapper`:
+
+```bash
+--set JAVA_HOME ${jdk.home}
+```
+
+It is possible to use a different Java compiler than `javac` from the
+OpenJDK. For instance, to use the GNU Java Compiler:
+
+```nix
+nativeBuildInputs = [ gcj ant ];
+```
+
+Here, Ant will automatically use `gij` (the GNU Java Runtime) instead of
+the OpenJRE.
diff --git a/doc/languages-frameworks/java.xml b/doc/languages-frameworks/java.xml
deleted file mode 100644
index 881d492b5bff..000000000000
--- a/doc/languages-frameworks/java.xml
+++ /dev/null
@@ -1,77 +0,0 @@
-<section xmlns="http://docbook.org/ns/docbook"
-         xmlns:xlink="http://www.w3.org/1999/xlink"
-         xml:id="sec-language-java">
- <title>Java</title>
-
- <para>
-  Ant-based Java packages are typically built from source as follows:
-<programlisting>
-stdenv.mkDerivation {
-  name = "...";
-  src = fetchurl { ... };
-
-  nativeBuildInputs = [ jdk ant ];
-
-  buildPhase = "ant";
-}
-</programlisting>
-  Note that <varname>jdk</varname> is an alias for the OpenJDK (self-built where available, or pre-built via Zulu). Platforms with OpenJDK not (yet) in Nixpkgs (<literal>Aarch32</literal>, <literal>Aarch64</literal>) point to the (unfree) <literal>oraclejdk</literal>.
- </para>
-
- <para>
-  JAR files that are intended to be used by other packages should be installed in <filename>$out/share/java</filename>. JDKs have a stdenv setup hook that add any JARs in the <filename>share/java</filename> directories of the build inputs to the <envar>CLASSPATH</envar> environment variable. For instance, if the package <literal>libfoo</literal> installs a JAR named <filename>foo.jar</filename> in its <filename>share/java</filename> directory, and another package declares the attribute
-<programlisting>
-buildInputs = [ libfoo ];
-nativeBuildInputs = [ jdk ];
-</programlisting>
-  then <envar>CLASSPATH</envar> will be set to <filename>/nix/store/...-libfoo/share/java/foo.jar</filename>.
- </para>
-
- <para>
-  Private JARs should be installed in a location like <filename>$out/share/<replaceable>package-name</replaceable></filename>.
- </para>
-
- <para>
-  If your Java package provides a program, you need to generate a wrapper script to run it using a JRE. You can use <literal>makeWrapper</literal> for this:
-<programlisting>
-nativeBuildInputs = [ makeWrapper ];
-
-installPhase =
-  ''
-    mkdir -p $out/bin
-    makeWrapper ${jre}/bin/java $out/bin/foo \
-      --add-flags "-cp $out/share/java/foo.jar org.foo.Main"
-  '';
-</programlisting>
-Since the introduction of the Java Platform Module System in Java 9, Java distributions typically no longer ship with a general-purpose JRE: instead, they allow generating a JRE with only the modules required for your application(s). Because we can't predict what modules will be needed on a general-purpose system, the default <package>jre</package> package is the full JDK. When building a minimal system/image, you can override the <literal>modules</literal> parameter on <literal>jre_minimal</literal> to build a JRE with only the modules relevant for you:
-<programlisting>
-let
-  my_jre = pkgs.jre_minimal.override {
-    modules = [
-      # The modules used by 'something' and 'other' combined:
-      "java.base"
-      "java.logging"
-    ];
-  };
-  something = (pkgs.something.override { jre = my_jre; });
-  other = (pkgs.other.override { jre = my_jre; });
-in
-  ...
-</programlisting>
- </para>
-
- <para>
-  Note all JDKs passthru <literal>home</literal>, so if your application requires environment variables like <envar>JAVA_HOME</envar> being set, that can be done in a generic fashion with the <literal>--set</literal> argument of <literal>makeWrapper</literal>:
-<programlisting>
---set JAVA_HOME ${jdk.home}
-</programlisting>
- </para>
-
- <para>
-  It is possible to use a different Java compiler than <command>javac</command> from the OpenJDK. For instance, to use the GNU Java Compiler:
-<programlisting>
-nativeBuildInputs = [ gcj ant ];
-</programlisting>
-  Here, Ant will automatically use <command>gij</command> (the GNU Java Runtime) instead of the OpenJRE.
- </para>
-</section>