Release/2.0.0 #94
Merged
Release/2.0.0 #94
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…h changes. While I recognize the intent of these changes, the manner in which it was implemented breaks existing workflows for CI builds and version checks in several environments I've been involved in. The inability to merge a feature or bugfix branch into a release branch (without mangling the version in the pom.xml) after the merge or without a merge conflict is a sticking point.
…rtifact (a .jar) to the snapshots repository.
…/integration-tests
… test for that. :-/
* added additional tests.
* Unified the jacoco reporting.
run integration tests in feature branches which assert proper branch behavior for all other plugins. Added the project-alt1-stub, which adds dependencies you can version enforce, allowing for full testing of the EnforceVersionsMojo.
Nearly all happy-paths in the AbstractGitflowBasedRepositoryMojo are covered. Once the remaining mojos are tested, we'll be basically validating error conditions.
…rced deployment of OTHER branches (long-running POCs).
… a few calls to verifier.resetStreams().
Feature/integration tests
…ypes.
* Inside the retarget, you need to set the project version -- this forms the basis for future attached artifacts.
* Existing artifacts need their version set (updated).
* Don't fiddle wiht the base version. that gets set when you update the version.
* Do fiddle with the VersionRange, as this sets up things to be able to be resolved properly when attaching the catalog artifact later.
* Failure to do so results in nullpointerexceptions in strange ways.
* Catch unsupported operation exception for some internal classes, and carry on your happy merry way.
* Added test case for attaching from an 'OTHER'. this does require that you run the VALIDATION phase, so that retarget-deploy can fiddle with the internal project state -- it's a bit wonky, but it works.
…nd reverted a mistaken edit on the IntelliJ comments.
Feature/deploy others semver
Added m2e lifecycle mappings
Feature/m2e mappings
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
otherBranchDeployPatternlets you define a regex for branch names to be deployed as snapshots. Branches matching this pattern will have build artifacts automatically versioned to include the branchname, and be SNAPSHOT versions, and will be targeted to the snapshots repository. You can attach these deployed artifacts from the same branch, or you can reference these artifacts in other projects (for long-running POCs).This should close the loop on providing the functionality of #83, in a backwards compatible manner that can be enabled / disabled as you see fit for your environment.