Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature/other branch reversioning extension #126

Merged
merged 19 commits into from Jan 14, 2021

Conversation

bvarner
Copy link
Contributor

@bvarner bvarner commented Jan 14, 2021

Pr for #105 I totally forgot what I was doing and put this into master earlier. Revert happening.

bvarner and others added 19 commits December 23, 2019 15:26
…oyment branches

* Pull up branch detection and plugin config extraction from the MasterPromotExtension to AbstractBranchDetectingExtension.
* Introduce OtherBranchVersionExtension, responsible for updating project versions based on the 'otherBranchDeploymentPattern'.
    * Updates project versions of MavenProjects in the reactor.
    * Parent references in the reactor model are by reference, so we don't have to update 'parent' relations on projects.
    * Iterates all reactor projects to update any (managed)dependencies or (managed)plugins.
* Removed artifact version manipulation from the RetargetDeployMojo -- which no longer needs to do that.
* Introduced basic multi-module IT stub.
    * Parent pom
    * Child modules with a dependency (Child2 -> depends upon -> Child1)

Notes:

* Still missing automated ITs on this - I was making this a 'poc' to see if it was feasible before I started writing exhaustive test cases.
* mvn initialize will fail for update-stage-dependencies on child2, however mvn package will succeed.
    * The lack of a resolvable dependency in the reactor, or in the remote stage repo keeps update-stage-dependencies from succeeding.
    * When the jar is built as part of the reactor, it finds the dep in the current reactor just fine. This is... wonky.
* I have not checked the output pom.xml's in the target to determine if their versions are being written based on the updates from the extension.
* Adjusts the artifact versions for the default project artifact.
    * Other artifacts attached by the build use these versions as the basis.
* Massage both effective in-memory models and original model (unalterd POM) of the project.
* Update project state (and hierarchy of projects) whereever possible.
* Retarget Deploy is really simple now. :-)
* Updates the OtherBranchVersionExtension to handle project massaging and emission of the massaged pom.
* The normal ProjectDeployer from maven-artifact-transfer works quite will with this POM swapping.
…ies from the main session to the nested maven execution
…e other branch suffix being applied to a version repeatedly (+normalized-branch-name+normalized-branch-name-SNAPSHOT)
…om:rdefreitas/gitflow-helper-maven-plugin into feature/partial-multi-module-reversioning
… execution. This is due to that additional execution clearing a ThreadLocal reference to the Session, that subsequent plugins/code may depend on (ie IntelliJ's Maven integration).
…e nested Maven execution. Changed from creating one from scratch, towards basing it on the request from the session, copying it, removing unneeded aspect and changing others.
…anch-renaming

Prevent repeated OtherBranch name suffixes being appended
…-reversioning

Extended the OtherBranchVersionExtension to deal with partial multi-module builds
…nit-4.13.1

Bump junit from 4.8.2 to 4.13.1
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants