Google Git
Sign in
apache/maven-archetypes/refs/heads/master
commit
815328266e7a922f10faeb711e539c5c17c4e3eb
[log]
author
Sylwester Lachiewicz <slachiewicz@apache.org>
Mon Aug 10 03:18:58 2026 +0200
committer
Sylwester Lachiewicz <slachiewicz@apache.org>
Mon Aug 10 03:28:57 2026 +0200
tree
54630e4d7ae9030f450c11948ec0c88805d224fd
parent
7e1268f132ef610d7fd1e78db83c5bbe0e8cd695 [diff]
Convert the demo archetypes' pages to Markdown

Both archetypes handed a generated project an APT src/site while shipping
Markdown examples beside it, so a new project started life with two
documentation formats and no reason to prefer either.

All four pages are content rather than format demonstration, so all four
are converted and none deleted. That is the difference from the site
archetype, where format.apt existed only to show what APT looks like and
has no Markdown equivalent worth writing.

Neither site descriptor needs a change: conversion does not rename a
generated page, so every href in both menus still resolves exactly as
before. Their entries for faq.html, plugin-info.html and the report pages
are template placeholders for the user to fill in and are untouched.

The reference fixture under site-simple's src/test/resources is the
expected generated output, so it carries the converted page too - it is
a copy of what the archetype now produces, and the integration test
compares the two.

Verified by running both archetypes' ITs, which generate a project and
build its site, before and after: both pass, the same pages are produced,
and every one is identical in text, metadata, structural tags and anchor
ids. The lone diff is an absolute path in distribution-management, which
differs because the two builds ran in different directories.

Generated-by: Claude Opus 5 (1M context)
5 files changed
tree: 54630e4d7ae9030f450c11948ec0c88805d224fd
  1. .github/
  2. maven-archetype-archetype/
  3. maven-archetype-j2ee-simple/
  4. maven-archetype-plugin/
  5. maven-archetype-plugin-site/
  6. maven-archetype-portlet/
  7. maven-archetype-profiles/
  8. maven-archetype-quickstart/
  9. maven-archetype-simple/
  10. maven-archetype-site/
  11. maven-archetype-site-simple/
  12. maven-archetype-site-skin/
  13. maven-archetype-webapp/
  14. src/
  15. .asf.yaml
  16. .gitignore
  17. Jenkinsfile
  18. LICENSE
  19. pom.xml
  20. README.md
README.md

Contributing to Apache Maven Archetype Bundles

Apache License, Version 2.0, January 2004 Maven Central Jenkins Status Jenkins tests

You have found a bug, or you have an idea for a cool new feature? Contributing code is a great way to give something back to the open source community. Before you dig right into the code, there are a few guidelines that we need contributors to follow so that we can have a chance of keeping on top of things.

Getting Started

  • Make sure you have a GitHub account.
  • If you‘re planning to implement a new feature, it makes sense to discuss your changes on the dev list first. This way you can make sure you’re not wasting your time on something that isn‘t considered to be in Apache Maven’s scope.
  • Submit a ticket for your issue, assuming one does not already exist.
    • Clearly describe the issue, including steps to reproduce when it is a bug.
    • Make sure you fill in the earliest version that you know has the issue.
  • Fork the repository on GitHub.

Making and Submitting Changes

We accept Pull Requests via GitHub. The developer mailing list is the main channel of communication for contributors.
There are some guidelines which will make applying PRs easier for us:

  • Create a topic branch from where you want to base your work (this is usually the master branch). Push your changes to a topic branch in your fork of the repository.
  • Make commits of logical units.
  • Respect the original code style: by using the same codestyle, patches should only highlight the actual difference, not being disturbed by any formatting issues:
    • Only use spaces for indentation.
    • Create minimal diffs - disable on save actions like reformat source code or organize imports. If you feel the source code should be reformatted, create a separate PR for this change.
    • Check for unnecessary whitespace with git diff --check before committing.
  • Make sure you have added the necessary tests (JUnit/IT) for your changes.
  • Run all the tests with mvn verify to assure nothing else was accidentally broken.
  • Submit a pull request to the repository in the Apache organization.

If you plan to contribute on a regular basis, please consider filing a contributor license agreement.

Making Trivial Changes

For changes of a trivial nature to comments and documentation, it is not always necessary to create a new ticket in JIRA. In this case, it is appropriate to start the first line of a commit with ‘(doc)’ instead of a ticket number.

Additional Resources