Add a Gradle example to README.md

README.md

@@ -77,6 +77,40 @@ to learn which properties you need to set (like `mavenReleaseRepoUrl`or
 
 <br/>
 
+## Usage from a Gradle project
+
+If your Gradle project depends on xml-dtd, you can use this project's own Maven
+repository in a `repositories` section of your build file:
+
+```groovy
+repositories {
+    maven {
+        url "https://css4j.github.io/maven/"
+        mavenContent {
+            releasesOnly()
+        }
+        content {
+            // Include io.sf.carte as well as other groups under io.sf
+            includeGroupByRegex 'io\\.sf\\..*'
+
+            // Alternative to the regex:
+            //includeGroup 'io.sf.carte'
+        }
+    }
+}
+```
+please use that repository only for the artifact groups that it supplies.
+
+Then, in your `build.gradle` file you can list the dependencies, for example:
+
+```groovy
+dependencies {
+    api 'io.sf.carte:xml-dtd:4.3'
+}
+```
+
+<br/>
+
 ## Software dependencies
 
 In case that you do not use a Gradle or Maven build (which would manage the

RELEASE_HOWTO.md

@@ -26,19 +26,20 @@ For reference, let your copy of the xml-dtd release code be at
 `/path/to/xml-dtd`.
 
 2) Use `changes.sh <new-version>` to create a `CHANGES.txt` file with the
-changes from the latest tag. For example if you are releasing `4.2.1`:
+changes from the latest tag. For example if you are releasing `4.3.1`:
 
 ```shell
 cd /path/to/xml-dtd
-./changes.sh 4.2.1
+./changes.sh 4.3.1
 ```
 
 Edit the resulting `CHANGES.txt` as convenient, to use it as the basis for the
 detailed list of changes when you fill the `RELEASE_NOTES.md` and the new
 release in Github.
 
-Complete the Release Notes and check whether the dependencies mentioned in the
-`README.md` are correct. Commit the changes.
+Complete the Release Notes and update the version in the Gradle example of
+`README.md`, also check whether the dependencies mentioned there are correct.
+Commit the changes.
 
 3) Bump the `version` in the [`build.gradle`](build.gradle) file or remove the
 `-SNAPSHOT` suffix as necessary. Commit and push all the changes to the Git
@@ -87,7 +88,7 @@ mv /path/to/css4j-dist/build/docs/javadoc/* /path/to/css4j.github.io/api/latest
 ```
 
 If the changes to the `css4j.github.io` repo look correct, commit them with a
-description like "Latest modular Javadocs after xml-dtd 4.2.1" and push.
+description like "Latest modular Javadocs after xml-dtd 4.3.1" and push.
 
 Check whether the ["Examples" CI](https://github.com/css4j/css4j.github.io/actions/workflows/examples.yml)
 triggered by that commit to the `css4j.github.io` repository completed
@@ -98,8 +99,8 @@ for example.
 
 ```shell
 cd /path/to/xml-dtd
-git tag -s v4.2.1 -m "Release 4.2.1"
-git push origin v4.2.1
+git tag -s v4.3.1 -m "Release 4.3.1"
+git push origin v4.3.1
 ```
 
 or `git tag -a` instead of `-s` if you do not plan to sign the tag. But it is