https://github.com/contentmunch/contentmunch-parent
https://github.com/contentmunch/contentmunch-parent
Last synced: 3 months ago
JSON representation
- Host: GitHub
- URL: https://github.com/contentmunch/contentmunch-parent
- Owner: contentmunch
- License: mit
- Created: 2021-08-19T10:43:49.000Z (almost 5 years ago)
- Default Branch: main
- Last Pushed: 2024-11-05T20:56:26.000Z (over 1 year ago)
- Last Synced: 2025-02-07T11:53:26.235Z (over 1 year ago)
- Size: 195 KB
- Stars: 0
- Watchers: 1
- Forks: 0
- Open Issues: 0
-
Metadata Files:
- Readme: README.md
- License: LICENSE
Awesome Lists containing this project
README
# contentmunch-parent
[](./LICENSE)
**Contentmunch Parent POM** for standardizing the build, dependency management, and plugin configuration across all contentmunch projects.
## Overview
This project defines a parent POM for the contentmunch ecosystem, providing:
- Centralized dependency management via BOMs.
- Shared plugin configuration (compiler, source, javadoc).
- Modules support.
- Java 21 compatibility.
## Modules
This parent project currently includes:
- contentmunch-bom
- contentmunch-foundation-spring-boot-starter
- contentmunch-auth-spring-boot-starter
## How to Use
In your Maven project, set `contentmunch-parent` as the parent:
```xml
com.contentmunch
contentmunch-parent
1.0.0
```
This gives your project:
* Java 21 setup
* Centralized dependency versions
* Automatic source/javadoc jars
* GPG signing support
* Plugin configurations
## Dependency Management
The parent imports:
* Spring Boot BOM
* OpenTelemetry BOM
* contentmunch-bom for internal library version alignment
These ensure all projects use compatible dependency versions out of the box.
## Coding Guidelines
We follow [GitHub Flow](https://guides.github.com/introduction/flow/) for development. To maintain a high-quality, maintainable codebase, please follow these guidelines:
---
### Workflow Rules
- Branch from `main` when starting work.
- Open pull requests **into `main`**.
- Ensure your code is covered by tests (unit/integration as appropriate).
- Keep your branch up to date with `main`.
- Follow the existing code style and structure.
---
### Pull Request Format
Your PR description should follow this format:
Short summary of the change
Key changes (bullet points)
* Any notes on why/how things are implemented (optional)
Closes #
```
Add support for user authentication
• Introduced login API with JWT support
• Added controller, service, and security config
• Updated README
Closes #42
```
---
### Git Commit Format
We follow the [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/) style:
Types
* feat: A new feature
* fix: A bug fix
* refactor: Internal code change without affecting behavior
* test: Adding or improving tests
* chore: Tooling, dependency updates, or minor infra changes
Notes:
* Use imperative, present tense: “add” not “added” or “adds”
* No trailing period in subject
* Max 100 characters for subject line
---
CI/CD and Quality
These are enforced via GitHub Actions and other automation tools.
- ✅ Tests must pass before merging
- ✅ PR should be reviewed and approved
- ✅ No merge conflicts
---