This is an automated email from the ASF dual-hosted git repository.
slachiewicz pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/maven-site.git
The following commit(s) were added to refs/heads/master by this push:
new 0ed5dbc2 fix snippet formats
0ed5dbc2 is described below
commit 0ed5dbc2d669c5b43f14d476a981c7ac9c2e78d5
Author: Sylwester Lachiewicz <[email protected]>
AuthorDate: Sat Dec 20 12:44:14 2025 +0100
fix snippet formats
---
content/markdown/plugin-developers/common-bugs.md | 22 +++++++++++-----------
.../cookbook/plexus-plugin-upgrade.md | 10 +++++-----
content/markdown/plugins/localization.md | 2 +-
.../repository/guide-central-repository-upload.md | 2 +-
4 files changed, 18 insertions(+), 18 deletions(-)
diff --git a/content/markdown/plugin-developers/common-bugs.md
b/content/markdown/plugin-developers/common-bugs.md
index 2abd57ef..f4b776ae 100644
--- a/content/markdown/plugin-developers/common-bugs.md
+++ b/content/markdown/plugin-developers/common-bugs.md
@@ -33,7 +33,7 @@ For example, if developer A has UTF-8 as default encoding
while developer B uses
Therefore, developers should avoid any direct or indirect usage of the
classes/methods that simply employ the platform's default encoding. For
instance, `FileWriter` and `FileReader` should usually be avoided:
-```unknown
+```java
/*
* FIXME: This assumes the source file is using the platform's default
encoding.
*/
@@ -49,7 +49,7 @@ To save the user from configuring each plugin individually,
conventions have bee
Finally note that XML files require special handling because they are equipped
with an encoding declaration in the XML prolog. Reading or writing XML files
with an encoding that does not match their XML prolog's `encoding` attribute is
a bad idea:
-```unknown
+```java
/*
* FIXME: This assumes the XML encoding declaration matches the platform's
default encoding.
*/
@@ -63,7 +63,7 @@ To ease the correct processing of XML files, developers are
encouraged to use [`
URLs and filesystem paths are really two different things and converting
between them is not trivial. The main source of problems is that different
encoding rules apply for the strings that make up a URL or filesystem path. For
example, consider the following code snippet and its associated console output:
-```unknown
+```java
File file = new File( "foo bar+foo" );
URL url = file.toURI().toURL();
@@ -84,7 +84,7 @@ First of all, please note that
[`File.toURL()`](http://java.sun.com/javase/6/doc
Next,
[`URL.getPath()`](http://java.sun.com/javase/6/docs/api/java/net/URL.html#getPath())
does in general not return a string that can be used as a filesystem path. It
returns a substring of the URL and as such can contain escape sequences. The
prominent example is the space character which will show up as "%20". People
sometimes hack around this by means of `replace("%20", " ")` but that does
simply not cover all cases. It's worth to mention that on the other hand the
related method [` [...]
-```unknown
+```java
URL url = new URL( "file:/C:/Program%20Files/Java/bin/java.exe" );
/*
@@ -97,7 +97,7 @@ To decode a URL, people sometimes also choose
[`java.net.URLDecoder`](http://jav
In an ideal world, code targetting JRE 1.4+ could easily avoid these problems
by using the constructor
[`File(URI)`](http://java.sun.com/javase/6/docs/api/java/io/File.html#File(java.net.URI))
as suggested by the following snippet:
-```unknown
+```java
URL url = new URL( "file:/C:/Documents and Settings/user/.m2/settings.xml" );
/*
@@ -116,7 +116,7 @@ When developers need to compare strings without regard to
case or want to realiz
The gotcha with the arg-less methods is that their output depends on the
default locale of the JVM but the default locale is out of control of the
developer. That means the string expected by the developer (who runs/tests his
code in a JVM using locale `xy`) does not necessarily match the string seen by
another user (that runs a JVM with locale `ab`). For example, the comparison
shown in the next code snippet is likely to fail for systems with default
locale Turkish because Turkish has u [...]
-```unknown
+```java
/*
* FIXME: This assumes the casing rules of the current platform
* match the rules for the English locale.
@@ -152,7 +152,7 @@ Reporting plugins that suffer from this bug can easily be
detected by executing
Maven's command line supports the definition of system properties via
arguments of the form `-D key=value`. While these properties are called system
properties, plugins should never use
[`System.getProperty()`](http://java.sun.com/javase/6/docs/api/java/lang/System.html#getProperty(java.lang.String))
and related methods to query these properties. For example, the following code
snippet will not work reliably when Maven is embedded, say into an IDE or a CI
server:
-```unknown
+```java
public class MyMojo extends AbstractMojo
{
public void execute()
@@ -171,7 +171,7 @@ The problem is that the properties managed by the `System`
class are global, i.e
People occasionally employ shutdown hooks to perform cleanup tasks, e.g. to
delete temporary files as shown in the example below:
-```unknown
+```java
public class MyMojo extends AbstractMojo
{
public void execute()
@@ -212,7 +212,7 @@ At first glance, one might be tempted to argue that the
project base directory i
Hence this example code is prone to misbehave:
-```unknown
+```java
public class MyMojo extends AbstractMojo
{
/**
@@ -233,7 +233,7 @@ public class MyMojo extends AbstractMojo
In order to guarantee reliable builds, Maven and its plugins must manually
resolve relative paths against the project's base directory. A simple idiom
like the following will do just fine:
-```unknown
+```java
File file = new File( path );
if ( !file.isAbsolute() )
{
@@ -249,7 +249,7 @@ Most reporting plugins inherit from `AbstractMavenReport`.
In doing so, they nee
Now, some plugins need to create additional files in the report output
directory that accompany the report generated via the sink interface. While it
is tempting to use either the method `getOutputDirectory()` or the field
`outputDirectory` directly in order to setup a path for the output files, this
leads most likely to a bug. More precisely, those plugins will not properly
output files when run by the Maven Site Plugin as part of the site lifecycle.
This is best noticed when the output [...]
-```unknown
+```java
public class MyReportMojo extends AbstractMavenReport
{
/**
diff --git
a/content/markdown/plugin-developers/cookbook/plexus-plugin-upgrade.md
b/content/markdown/plugin-developers/cookbook/plexus-plugin-upgrade.md
index 23150d0e..d3cf0204 100644
--- a/content/markdown/plugin-developers/cookbook/plexus-plugin-upgrade.md
+++ b/content/markdown/plugin-developers/cookbook/plexus-plugin-upgrade.md
@@ -63,7 +63,7 @@ Here is the list of the plugins used:
In your `pom.xml`, replace `plexus-maven-plugin` configuration:
-```unknown
+```xml
<project xmlns="http://maven.apache.org/POM/4.0.0";>
<build>
<plugins>
@@ -85,7 +85,7 @@ In your `pom.xml`, replace `plexus-maven-plugin`
configuration:
with corresponding `plexus-component-metadata` configuration:
-```unknown
+```xml
<project xmlns="http://maven.apache.org/POM/4.0.0";>
<build>
<plugins>
@@ -111,7 +111,7 @@ If `merge-descriptors` is used, move the handwritten xml
file to `${project.base
In your `pom.xml`, add `plexus-component-annotations` dependency:
-```unknown
+```xml
<project xmlns="http://maven.apache.org/POM/4.0.0";>
<dependencies>
<dependency>
@@ -125,7 +125,7 @@ In your `pom.xml`, add `plexus-component-annotations`
dependency:
In your java sources, replace javadoc tags:
-```unknown
+```java
/**
* @plexus.component role="foo.MyComponent" role-hint="hint-value"
*/
@@ -141,7 +141,7 @@ public class MyComponentImplementation
with corresponding Java 5 annotations
-```unknown
+```java
import org.codehaus.plexus.component.annotations.Component;
import org.codehaus.plexus.component.annotations.Requirement;
diff --git a/content/markdown/plugins/localization.md
b/content/markdown/plugins/localization.md
index b81a33df..eee17985 100644
--- a/content/markdown/plugins/localization.md
+++ b/content/markdown/plugins/localization.md
@@ -55,7 +55,7 @@ Is your favourite plugin missing a localization for your
language? Please help u
- Run "mvn install" for the plugin.
- Configure a project to use the latest SNAPSHOT version of the plugin you are
working on. Also configure the project to produce a site in the language you
are adding a translation for. For Spanish, as we used in the example above, it
would look like this:
- ```unknown
+ ```xml
<build>
<plugins>
<plugin>
diff --git a/content/markdown/repository/guide-central-repository-upload.md
b/content/markdown/repository/guide-central-repository-upload.md
index 4ff3193a..6f14b7ee 100644
--- a/content/markdown/repository/guide-central-repository-upload.md
+++ b/content/markdown/repository/guide-central-repository-upload.md
@@ -33,7 +33,7 @@ In order for Maven users to depend on your project, you must
deploy the artifact
## A basic sample:
-```unknown
+```xml
<project xmlns="http://maven.apache.org/POM/4.0.0";>
<modelVersion>4.0.0</modelVersion>
