aleksandr-m / gitflow-maven-plugin

The Git-Flow Maven Plugin supports various Git workflows, including GitFlow and GitHub Flow. This plugin runs Git and Maven commands from the command line.
https://aleksandr-m.github.io/gitflow-maven-plugin/
Apache License 2.0
492 stars 182 forks source link

property value as version in pom not resolved (missing property evaluation) #195

Closed vinsgithub closed 5 years ago

vinsgithub commented 5 years ago

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.

aleksandr-m commented 5 years ago

Should be already implemented since https://github.com/aleksandr-m/gitflow-maven-plugin/issues/151.

vinsgithub commented 5 years ago

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. `

0.0.4-SNAPSHOT
</properties>`

after feature start should be `

0.0.4-test-SNAPSHOT
</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.

aleksandr-m commented 5 years ago

Does it mean that flatten plugin is not needed in that case?

vinsgithub commented 5 years ago

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 `

2
        <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>`
aleksandr-m commented 5 years ago

@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 commented 5 years ago

@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?

vinsgithub commented 4 years ago

@aleksandr-m I wish not to appear as a nitpicking guy, have you considered my last comment? Please let me know. Thank you.

aleksandr-m commented 4 years ago

@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 commented 4 years ago

@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).