Closed vinsgithub closed 5 years ago
Should be already implemented since https://github.com/aleksandr-m/gitflow-maven-plugin/issues/151.
Yes, it's implemented but the revision property does not get evaulated.
Please have a look to https://github.com/openmindlab/gitflow-maven-plugin/tree/master/src/it/feature-start-3-it
@aleksandr-m If you run that test, it fails.
This is because it simply reads the value of "revision" from original pom.xml and reports it on new without evaluation.
`
</properties>`
after feature start should be
`
</properties>`
as featureName is "test" (see invoker.properties in my test). I hope I didn't miss something. My PR just introduced evaluation as maven itself (with effettive pom) does.
Does it mean that flatten plugin is not needed in that case?
As far as I can tell, when invoking "mvn gitflow:feature-start" maven runs GitFlowFeatureStartMojo without any particular phase defined so no flatten-plugin (which typically is bound to process-resource phase ) will be invoked and have any effect even if <updatePomFile>true</updatePomFile>
has been set in its configuration.
In my project, I already had flatten-plugin setup exactly as maven suggested for "ci-friendly" builds but feature-start didn't work properly (feature name was missing in revision property for example). Then I realized I had to fix it. To answer your question, I think that flatten-plugin is still needed even after my PR. This is becuase it's necessary when installing or deploying artifact indipendenlty from invoking gitflow-plugin, I think.
Please, let me know your thoughts/tests about it.
My current plugin setup is
`
<useSnapshotInRelease>true</useSnapshotInRelease>
<verbose>true</verbose>
<keepBranch>true</keepBranch>
<fetchRemote>true</fetchRemote>
<pushRemote>true</pushRemote>
<skipFeatureVersion>true</skipFeatureVersion>
<postReleaseGoals>deploy</postReleaseGoals>
<postHotfixGoals>deploy</postHotfixGoals>
<skipFeatureVersion>true</skipFeatureVersion>
<versionProperty>revision</versionProperty>
<skipUpdateVersion>true</skipUpdateVersion>
<argLine>-DperformRelease=${performRelease} ${maven.settings.hook}</argLine>
<gitFlowConfig>
<productionBranch>master</productionBranch>
<developmentBranch>develop</developmentBranch>
<featureBranchPrefix>feature/</featureBranchPrefix>
<releaseBranchPrefix>release/</releaseBranchPrefix>
<hotfixBranchPrefix>hotfix/</hotfixBranchPrefix>
<versionTagPrefix>v</versionTagPrefix>
</gitFlowConfig>
<commitMessages>
<featureStartMessage>create feature-branch '@{featureName}' - update version to v@{version}</featureStartMessage>
<featureFinishMessage>merge feature-branch '@{featureName}' - update version to v@{version}</featureFinishMessage>
<hotfixStartMessage>update version for hotfix to v@{version}</hotfixStartMessage>
<hotfixFinishMessage>update for next development version to v@{version}</hotfixFinishMessage>
<releaseStartMessage>update version for release to v@{version}</releaseStartMessage>
<releaseFinishMessage>update for next development version to v@{version}</releaseFinishMessage>
</commitMessages>
</configuration>`
@vinsgithub You are right about phases. You need to run flatten
goal explicitly e.g.:
mvn flatten:flatten gitflow:release
I've updated readme with this information.
@vinsgithub You are right about phases. You need to run
flatten
goal explicitly e.g.:mvn flatten:flatten gitflow:release
I've updated readme with this information.
@aleksandr-m IMHO it's just a forced (and error prone) workaround. Replacing to <properties> <revision>0.0.4-test-SNAPSHOT</revision> </properties>
should be done independently from flatten usage when you are starting a feature/hotfix/release because flatten is meant to be implicitly used during install and deploy...
My PR passes all tests, so I cannot see any drawback in merging it. Am I missing something?
@aleksandr-m I wish not to appear as a nitpicking guy, have you considered my last comment? Please let me know. Thank you.
@vinsgithub Can you take a look at this PR https://github.com/aleksandr-m/gitflow-maven-plugin/pull/204. Looks like with this approach there is no need to call flatten or help plugin.
@vinsgithub Can you take a look at this PR #204. Looks like with this approach there is no need to call flatten or help plugin.
That's ok (see my comment to PR #204 ). You can consider to merge my own test as a proven testcase (feature-start-3-it).
resolved the problem of having a property value in current project tag. This is a common setup for CI-friendly maven versioning. See feature-start-3-it test case.