This is a maven plugin that allows for developers and organizations to ban Maven artifacts. We are keenly aware of the capability in the `maven-enforcer-plugin`. Instead of simply generating an error when a banned artifact is referenced, this plugin prevents the artifact from being downloaded as well. This is crucial within certain organizations with strict security scans that crawl the Maven cache.
This is a maven plugin that allows developers and organizations to ban Maven artifacts. We are keenly aware of the capability in the `maven-enforcer-plugin`. Instead of simply generating an error when a banned artifact is referenced, this plugin prevents the artifact from being downloaded as well. This is crucial within certain organizations with strict security scans that crawl the Maven cache.
## Extension
@@ -33,6 +33,8 @@ When using as an extension, it will enforce a ban on the configured dependencies
The `extensions` elements is critical. Without it, the plugin does nothing as far as banning artifacts/dependencies. With it, the plugin is able to not only detect banned artifacts, but do it before they are downloaded. This keeps libraries from even reaching your local Maven repository cache.
A module project will inherit the `extensions` setting from its parent project. A project with the extension (whether declared or inherited) will inherit the plugin configurations of its ancestral projects.
### Configuration
| Element | Description |
@@ -45,7 +47,7 @@ The `extensions` elements is critical. Without it, the plugin does nothing as f
When specifying `artifact`, you can use any of the following formats. The example is of this library; just replace the values to match the artifacts you want to ban.
- Exact artifact; all versions: `com.inteligr8:ban-maven-plugin`
- Exact artifact; version range: `com.inteligr8:ban-maven-plugin:[,1.4.0)`
- All artifacts/versions in group: `org.springframework:`
@@ -72,15 +74,15 @@ It supports the use of regular expressions with `groupIdRegex` and `artifactIdRe
</artifact>
```
If no `includes` are provided, then no artifacts will be banned. An *included* artifact is a banned artifact. An *excluded* artifact is not banned. It is the opposite of what you may think. If no `excludes` are provided, then no banned artifacts are granted an exception.
If no `includes` are provided, then no artifacts will be banned. An *included* artifact is a banned artifact. An *excluded* artifact is not banned. It may be the opposite of what you think. If no `excludes` are provided, then no banned artifacts are granted an exception.
The `artifact` element supports the descriptive `groupId`/`artifactId`/`version` elements or the abbreviated colon-based notation. When using the colon-based notation, the group ID and artifact ID may be treated as `groupIdRegex` and `artifactIdRegex` (see below). If you only use acceptable `groupId` and `artifactId` characters (letters/numbers/dashes/underscores/dots), it will not. But if you include any other characters, like `\.` or `*`, then it will be treated as regex. How it is treated will impact the functionality of `purge-repo` goal, if you are using it.
If `groupId` or `artifactId` or `version` are not provided, they are ignored in the matching process. So it will match all applicable artifacts and the constraint will be only for what was specified. This means that `<includes><artifact>:</artifact></includes>` will ban every artifact and all their versions.
If `groupId` and `groupIdRegex` are both provided, only `groupId` is used. The same is true for `artifactId` and `artifactIdRegex`. The `*Regex` element values use standard Java regular expression parsing. If using regular expressions, remember to escape the dots (`\.`) in group IDs. If you do use `groupIdRegex` or use regular expressions in the colon-notation, the matching artifacts will not be purged using the `purge-repo` goal. So if you intend to use that goal, group ID regular expression matching needs be avoided.
If `groupId` and `groupIdRegex` are both provided, only `groupId` is used. The same is true for `artifactId` and `artifactIdRegex`. The `*Regex` element values use standard Java regular expression parsing. If using regular expressions, remember to escape the dots (`\.`) in group IDs. If you do use `groupIdRegex` or use regular expressions in the group part of the colon-notation, the matching artifacts will not be purged using the `purge-repo` goal. So if you intend to use that goal, group ID regular expression matching needs be avoided.
The `version` element supports the standard Maven specification. You can match a specific version like `1.0.0`. Or you can match all versions before `1.2.17` like `[,1.2.17)`. You can match all future versions after `1.2.17` (inclusive) with `[1.2.17,)`.
The `version` element supports the standard [Maven version specification](https://maven.apache.org/enforcer/enforcer-rules/versionRanges.html). You can match a specific version like `[1.0.0]`. Or you can match all versions before `1.2.17` like `[,1.2.17)`. You can match all future versions after `1.2.17` (inclusive) with `[1.2.17,)`. The bracket-less `1.0.0` is not the same as `[1.0.0]`.
There is nothing stopping you from specifying two `artifact` elements with the exact same values. So you can ban multiple version ranges of the same artifact by using multiple `artifact` elements.
@@ -142,7 +144,7 @@ This goal will purge the local Maven repository of banned artifacts. The most c
This goal does **NOT support**`groupIdRegex` or blank `groupId` specifications. So any of those will be ignored not be purged/removed (if in `includes`).
This goal does **NOT support**`groupIdRegex` or blank `groupId` specifications. So any of those will be ignored and not be purged/removed (if in `includes`).
#### Configuration
@@ -160,7 +162,7 @@ The following additional elements/properties are supported:
