An extension and plugin that teaches Maven to work well with gitflow projects and CI servers.
Just in time to induce Holiday Panic...
The only way to define a repository for targeting now is by the repo ID. This solves issues folks were having with authn/z on repos, and makes Wagon extensions (S3 buckets as a repo) viable.
This will require some mirror / repository configuration either in your pom, or a profile in your settings.xmls (any of them will do). The documentation has been updated to properly reflect expected configurations.
Release 2.2.0 is out, with fixes for #104, and some documentation updates.
Ongoing work toward future issues will be rolled up into the next release.
Thanks to those who patiently waited for this release, and for helping patch / resolve issues.
Thanks to the community report in #101 this hotfix resolves the issue by bumping a few dependency versions.
In cases where a +
is not a legal character for version strings, this release lets you change the delimiter to something else.
This specifically came about as a consequence of trying to push docker images with mutable tags based off the project version -- where the tag format prohibits the use of +
.
This release fixes a regression regarding how enforce versions treated non-released (other) branches introduced in 1.8.0. Even if you weren't trying to release your feature branches to the snapshots repo some assertions began to happen on feature and bugfix branches that were not originally part of this plugin.
This restores the original behavior against non-release creating branches, and adds the ability to automagically generate -snapshot artifacts for those branches, if you so choose.
A way overdue release with loads of improvements.
Resolves a couple of bugs around SCM interaction.
<scm>
block without either a <developerConnection>
or <connection>
(common in spring boot apps), and the child project didn't define a connection URL, the result was a null pointer exception (Issue #74)The 1.7.0 release introduced support for support branches, but the promote extension didn't modify the build process. Somehow I missed that in testing.
This release does a few things with repositories and how we handle local & remote repos.
update-stage-dependencies
is a new goal that can purge local repository release versions previously resolved from the 'stage' repository. This should resolve most of the issue documented in #50.As always, this release is Available in Maven Central
Rather than relying only upon environment variables injected by CI servers, we now leverage the SCM definition of the project wherever possible. This has had the following consequences:
(origin/)?
prefix.enforce-versions
now expects the last subgroup from a match to equal the project version.${env.GIT_BRANCH}
the plugin / extension will now use a developerConnection
, connection
, or ${env.GIT_BRANCH}
(or the expression you provide) in that order, to resolve git branch, and to handle tagging.git symbolic-ref HEAD | sed 's/refs\/heads\///'
being executed in the project base directory. Hence the optional sub-group match for (origin/)?
now being part of the default patterns.(origin/)?develop
. If you were using the highly opinionated and verbose origin/development
name, then you should specify this inside your plugin configuration.developmentBranchPattern
. You may need to specify one now (if you're using 'development' rather than 'develop')gitBranchExpression
, consider using the <scm>
block of your project to define a <developerConnection>
.<scm>
block to make sure you have the Git SCM URLs correctly formatted.