Skip to content

Commit 8fd0de1

Browse files
committed
Update README.md
1 parent 2d335f1 commit 8fd0de1

File tree

2 files changed

+16
-16
lines changed

2 files changed

+16
-16
lines changed

README.md

Lines changed: 8 additions & 8 deletions
Original file line numberDiff line numberDiff line change
@@ -7,13 +7,13 @@ This plugin is used to initialise `git` submodules in Maven projects. An absolut
77
When working with Maven projects that have `git` submodules, it is often necessary to clone the submodules before
88
building. This is especially true when performing releases, as the submodules aren't initialised by the
99
`maven-release-plugin` when building in a sandbox. This is a problem we've faced regularly in the past, most notably
10-
with our [java-tree-sitter](https://github.com/seart-group/java-tree-sitter) project, and more recently with
11-
[jcloc](https://github.com/seart-group/jcloc). The only [solution](https://stackoverflow.com/q/6938142/17173324)
12-
proposed by the community involved the use of the `exec-maven-plugin` to run a recursive initialisation and update of
13-
submodules within a project. Although viable, frequently copying and pasting the same configuration across projects
14-
tends to get annoying after the first few times. This is without mentioning the technical debt that would be incurred by
15-
having to maintain the same configuration in multiple projects. This project was born out a necessity to provide a more
16-
Maven-like, drop-in solution to the described problem.
10+
with our [java-tree-sitter](https://github.com/seart-group/java-tree-sitter) project. The only
11+
[solution](https://stackoverflow.com/q/6938142/17173324) proposed by the community involved the use of the
12+
`exec-maven-plugin` to run a recursive initialisation and update of submodules within a project. Although viable,
13+
frequently copying and pasting the same configuration across projects tends to get annoying after the first few times.
14+
This is without mentioning the technical debt that would be incurred by having to maintain the same configuration in
15+
multiple projects. This project was born out a necessity to provide a more Maven-like, drop-in solution to the described
16+
problem.
1717

1818
## Requirements
1919

@@ -23,7 +23,7 @@ Maven-like, drop-in solution to the described problem.
2323
> [!NOTE]
2424
> Although it operates on Git submodules, this plugin doesn't require `git` to be installed on the system. Instead, it
2525
> uses the Eclipse [JGit](https://www.eclipse.org/jgit/) library to interact with the VCS through Java. As a result, the
26-
> plugin will still work in containerised environments such as Docker containers and CI/CD pipelines.
26+
> plugin will still work in environments such as Docker containers and CI/CD pipelines.
2727
2828
## Usage
2929

doc/README.md

Lines changed: 8 additions & 8 deletions
Original file line numberDiff line numberDiff line change
@@ -7,13 +7,13 @@ This plugin is used to initialise `git` submodules in Maven projects. An absolut
77
When working with Maven projects that have `git` submodules, it is often necessary to clone the submodules before
88
building. This is especially true when performing releases, as the submodules aren't initialised by the
99
`maven-release-plugin` when building in a sandbox. This is a problem we've faced regularly in the past, most notably
10-
with our [java-tree-sitter](https://github.com/seart-group/java-tree-sitter) project, and more recently with
11-
[jcloc](https://github.com/seart-group/jcloc). The only [solution](https://stackoverflow.com/q/6938142/17173324)
12-
proposed by the community involved the use of the `exec-maven-plugin` to run a recursive initialisation and update of
13-
submodules within a project. Although viable, frequently copying and pasting the same configuration across projects
14-
tends to get annoying after the first few times. This is without mentioning the technical debt that would be incurred by
15-
having to maintain the same configuration in multiple projects. This project was born out a necessity to provide a more
16-
Maven-like, drop-in solution to the described problem.
10+
with our [java-tree-sitter](https://github.com/seart-group/java-tree-sitter) project. The only
11+
[solution](https://stackoverflow.com/q/6938142/17173324) proposed by the community involved the use of the
12+
`exec-maven-plugin` to run a recursive initialisation and update of submodules within a project. Although viable,
13+
frequently copying and pasting the same configuration across projects tends to get annoying after the first few times.
14+
This is without mentioning the technical debt that would be incurred by having to maintain the same configuration in
15+
multiple projects. This project was born out a necessity to provide a more Maven-like, drop-in solution to the described
16+
problem.
1717

1818
## Requirements
1919

@@ -23,7 +23,7 @@ Maven-like, drop-in solution to the described problem.
2323
> [!NOTE]
2424
> Although it operates on Git submodules, this plugin doesn't require `git` to be installed on the system. Instead, it
2525
> uses the Eclipse [JGit](https://www.eclipse.org/jgit/) library to interact with the VCS through Java. As a result, the
26-
> plugin will still work in containerised environments such as Docker containers and CI/CD pipelines.
26+
> plugin will still work in environments such as Docker containers and CI/CD pipelines.
2727
2828
## Usage
2929

0 commit comments

Comments
 (0)