)

    nullawayEnabled.convention(false)
}

nullaway {
    // NullAway can use NullMarked instead, but for the adoption process it is more effective to assume that all gradle code is already annotated.
    // This way we can catch discrepancies in modules easier. We should make all packages NullMarked eventually too, but this is a separate task.
    annotatedPackages.add("org.gradle")
}

dependencies {

    }

    @Test
    public void test_formatCode() {
        String code;
        String value;

        code = "";
        value = FessFunctions.formatCode("L", "prettyprint", "text/plain", code);
        assertEquals("<pre class=\"prettyprint\"></pre>", value);

        code = "aaa";
        value = FessFunctions.formatCode("L", "prettyprint", "text/plain", code);
        assertEquals("<pre class=\"prettyprint\">aaa</pre>", value);

    /** Error code for request timeout. */
    public static final String ERROR_TIMEOUT = "timeout";

    /** Error code for context length exceeded. */
    public static final String ERROR_CONTEXT_LENGTH_EXCEEDED = "context_length_exceeded";

    /** Error code for model not found. */
    public static final String ERROR_MODEL_NOT_FOUND = "model_not_found";

    /** Error code for invalid response from the LLM provider. */

We utilize nullness annotations in Java code and somewhat rely on IDE warnings to guide us.
However, the Java code we have is not fully annotated, which causes several consequences:
* IDE warnings can be misleading
* Redundant null checks may increase binary size, hurt performance, and increase cognitive load for readers
* Missing null checks may cause NullPointerException
* Bridging with Kotlin code is polluted with platform types

### Negative Consequences

* **Historical inconsistencies**: Existing code may contain British English spellings that cannot be changed due to backward compatibility

### Migration and Enforcement

* **New code**: All new contributions must use American English
* **Existing code**: British English spellings in existing code should be updated opportunistically when those areas are modified, unless constrained by backward compatibility

  <error-page>
    <error-code>400</error-code>
    <location>/WEB-INF/view/error/redirect.jsp?type=badRequest</location>
  </error-page>
  <error-page>
    <error-code>401</error-code>
    <location>/WEB-INF/view/error/redirect.jsp?type=badAuth</location>
  </error-page>
  <error-page>
    <error-code>403</error-code>
    <location>/WEB-INF/view/error/redirect.jsp?type=logOut</location>

        String result = markdownRenderer.render("Use `code` here");
        assertTrue(result.contains("<code>code</code>"));
    }

    @Test
    public void test_render_codeBlock() {
        String markdown = "```\ncode block\n```";
        String result = markdownRenderer.render(markdown);
        assertTrue(result.contains("<pre>"));
        assertTrue(result.contains("<code>"));
        assertTrue(result.contains("code block"));

- ACCEPTED on 2024-02-07

## Context

The Gradle code base is essentially a large monolith, without strong internal boundaries.
This has a number of negative effects on productivity, including:

- Unclear ownership of code.
- Difficult to focus on one particular area.
- Unintended coupling between areas of the code, including tests.

## Decision

Organize the Gradle code base into a set of coarse-grained "architecture modules".

* They are not synced with the code to reflect the eventual solution that is committed
* Google Docs is not a "code-oriented" tool, like Markdown can be
* Review in Google Docs is not as simple as a PR code review in GitHub

## Decision

```

### Running
```bash
./bin/fess              # From command line
# Or run org.codelibs.fess.FessBoot from IDE
# Access: http://localhost:8080/ (Admin: admin/admin)
```

### Code Formatting
```bash
mvn formatter:format    # Format code
mvn license:format      # Add license headers
```

## Directory Structure

```
src/main/java/org/codelibs/fess/
├── FessBoot.java              # Application entry point