Fix trailing cross-references

Makefile

@@ -39,7 +39,7 @@ clean:
 	@rm -rfv build cache public $(generated_sources)
 
 index.html: $(pages) $(examples) $(generated_sources)
-	asciidoctor -a EXAMPLE='../examples/' -o $@ $(source_dir)/pages/index.adoc --failure-level=ERROR
+	asciidoctor -v -a EXAMPLE='../examples/' -o $@ $(source_dir)/pages/index.adoc --failure-level=ERROR
 
 $(call manpage_html,%):
 	COLUMNS=80 man -Tutf8 7 $(*F) | ansi2html >$@

index.html

@@ -1193,7 +1193,7 @@ <h4 id="_example_rpm_project">1.3.1. Example RPM Project</h4>
 <div class="paragraph">
 <p>We packed the project directory into file <code>helloworld.tar.gz</code>.</p>
 </div>
-<div class="listingblock">
+<div id="helloworld_spec" class="listingblock">
 <div class="title">Example spec file</div>
 <div class="content">
 <pre class="rouge highlight"><code data-lang="rpmspec"><table class="linenotable"><tbody><tr><td class="linenos gl"><pre class="lineno"> 1
@@ -1456,7 +1456,7 @@ <h4 id="_example_rpm_project">1.3.1. Example RPM Project</h4>
 </dl>
 </div>
 <div class="paragraph">
-<p>To build RPM from <a href="rpm_project/helloworld.spec">this <code>spec</code> file</a> save it in your current directory and run <code>rpmbuild</code>:</p>
+<p>To build RPM from <a href="#helloworld_spec">this <code>spec</code> file</a> save it in your current directory and run <code>rpmbuild</code>:</p>
 </div>
 <div class="listingblock">
 <div class="content">
@@ -1878,7 +1878,7 @@ <h4 id="_artifact_specification">3.2.2. Artifact specification</h4>
 <div class="paragraph">
 <p>In Linux distributions it is important to stay close to upstreams providing software being packaged, so the ability to identify artifacts in the same way as upstream does is very important from the packaging point of view.
 Every artifact can optionally be identified by artifact coordinates assigned during package build.
-Packages built with Maven automatically use this feature, but all other packages, even these built with pure <code>javac</code>, can use this feature too (see description of <a href="#_installing_additional artifacts"><code>%mvn_artifact</code></a> and <a href="#_add_maven_depmap_macro"><code>%add_maven_depmap</code></a> macros).</p>
+Packages built with Maven automatically use this feature, but all other packages, even these built with pure <code>javac</code>, can use this feature too (see description of <a href="#_installing_additional_artifacts"><code>%mvn_artifact</code></a> and <a href="#_add_maven_depmap_macro"><code>%add_maven_depmap</code></a> macros).</p>
 </div>
 </div>
 <div class="sect3">
@@ -1968,7 +1968,7 @@ <h5 id="_maven_compat_versions">Maven Compat Versions</h5>
 <p>XMvn supports marking particular artifact as compat, performing the necessary steps to avoid clashes with the non-compat version.
 An artifact can be marked as compat by <code>%mvn_compat_version</code>.
 It accepts an artifact argument which will determine which artifact will be compat.
-The format for specifying artifact coordinates is the same as with <a href="#mvn_alias"><code>%mvn_alias</code></a>.
+The format for specifying artifact coordinates is the same as with <a href="#_mvn_alias"><code>%mvn_alias</code></a>.
 In the common case you will want to mark all artifacts as compat. You can specify multiple compat versions at a time.</p>
 </div>
 <div class="paragraph">
@@ -2105,7 +2105,7 @@ <h3 id="_dependency_handling">3.3. Dependency Handling</h3>
 <h3 id="_javadoc_packages">3.4. Javadoc packages</h3>
 <div class="paragraph">
 <p>Javadoc subpackages in Fedora provide automatically generated API documentation for Java libraries and applications.
-<a href="#openjdk">Java Development Kit</a> comes with tool called <code>javadoc</code>.
+<a href="#_java_implementation_in_fedora">Java Development Kit</a> comes with tool called <code>javadoc</code>.
 This tool can be used for generating the documentation from specially formated comments in Java source files.
 Output of this tool, together with license files, usually represents only content of javadoc subpackages.
 Note <code>javadoc</code> invocation is typically handled by build system and package maintainer does not need to deal with it directly.</p>
@@ -3405,7 +3405,7 @@ <h3 id="_compilation_failure">8.2. Compilation failure</h3>
 If the library in local repository is older than the one required by project, then the library could be updated.
 If the project requires older version, then the project should be ported to latest stable version of the library (this may require cooperation with project&#8217;s upstream).
 If none of these is possible from some reason, it is still possible to introduce new <code>compat</code> package.
-See <a href="#compatibility_versions">compat packages</a> section for more information on this topic.</p>
+See <a href="#_compatibility_versions">compat packages</a> section for more information on this topic.</p>
 </div>
 <div class="paragraph">
 <p>Sometimes <code>pom.xml</code> doesn&#8217;t list all the necessary dependencies, even if it should.

modules/ROOT/pages/common_errors.adoc

@@ -55,7 +55,7 @@ This means that project doesn't have to be buildable if different version is pro
 If the library in local repository is older than the one required by project, then the library could be updated.
 If the project requires older version, then the project should be ported to latest stable version of the library (this may require cooperation with project's upstream).
 If none of these is possible from some reason, it is still possible to introduce new `compat` package.
-See <<compatibility_versions, compat packages>> section for more information on this topic.
+See <<_compatibility_versions, compat packages>> section for more information on this topic.
 
 Sometimes `pom.xml` doesn't list all the necessary dependencies, even if it should.
 Dependencies can also depend on some other and typically all these will be available to the project which is being built.

modules/ROOT/pages/introduction_for_developers.adoc

@@ -35,6 +35,7 @@ src/org/fedoraproject/helloworld/HelloWorld.java
 
 We packed the project directory into file `helloworld.tar.gz`.
 
+[#helloworld_spec]
 .Example spec file
 [source,rpmspec,numbered]
 ----
@@ -86,7 +87,7 @@ Unit test are usually run in `%build` section, so if there are no integration te
 * Has prescribed format.
 To prevent mistakes in format, it is advised to use tool such as `rpmdev-bumpspec` from package rpmdevtools to append new changelog entries instead of editing it by hand.
 
-To build RPM from link:rpm_project/helloworld.spec[this `spec` file] save it in your current directory and run `rpmbuild`:
+To build RPM from <<helloworld_spec, this `spec` file>> save it in your current directory and run `rpmbuild`:
 [source,shell]
 ----
 $ rpmbuild -bb helloworld.spec

modules/ROOT/pages/jar_file_id_artifact.adoc

@@ -9,4 +9,4 @@ Besides group ID and artifact ID, artifact coordinates may also include other op
 
 In Linux distributions it is important to stay close to upstreams providing software being packaged, so the ability to identify artifacts in the same way as upstream does is very important from the packaging point of view.
 Every artifact can optionally be identified by artifact coordinates assigned during package build.
-Packages built with Maven automatically use this feature, but all other packages, even these built with pure `javac`, can use this feature too (see description of <<_installing_additional artifacts, `%mvn_artifact`>> and <<_add_maven_depmap_macro, `%add_maven_depmap`>> macros).
+Packages built with Maven automatically use this feature, but all other packages, even these built with pure `javac`, can use this feature too (see description of <<_installing_additional_artifacts, `%mvn_artifact`>> and <<_add_maven_depmap_macro, `%add_maven_depmap`>> macros).

modules/ROOT/pages/jar_file_id_compat.adoc

@@ -22,7 +22,7 @@ If the upstream is already inactive and the package is not required by anything,
 XMvn supports marking particular artifact as compat, performing the necessary steps to avoid clashes with the non-compat version.
 An artifact can be marked as compat by `%mvn_compat_version`.
 It accepts an artifact argument which will determine which artifact will be compat.
-The format for specifying artifact coordinates is the same as with <<mvn_alias,`%mvn_alias`>>.
+The format for specifying artifact coordinates is the same as with <<_mvn_alias,`%mvn_alias`>>.
 In the common case you will want to mark all artifacts as compat. You can specify multiple compat versions at a time.
 
 .Dependency resolution of compat artifacts

modules/ROOT/pages/javadoc_packages.adoc

@@ -1,6 +1,6 @@
 === Javadoc packages
 Javadoc subpackages in Fedora provide automatically generated API documentation for Java libraries and applications.
-<<openjdk, Java Development Kit>> comes with tool called `javadoc`.
+<<_java_implementation_in_fedora, Java Development Kit>> comes with tool called `javadoc`.
 This tool can be used for generating the documentation from specially formated comments in Java source files.
 Output of this tool, together with license files, usually represents only content of javadoc subpackages.
 Note `javadoc` invocation is typically handled by build system and package maintainer does not need to deal with it directly.