Plugin Allows Releases of Projects with SNAPSHOT parent POMs

[lorkpoin]

Expected behavior:
If I attempt to release a project with the following lines in the pom.xml, I expect the release to fail along the same lines as if I had a SNAPSHOT dependency:

<parent>
      <groupId>com.mypackage.whatever</groupId>
      <artifactId>some-project</artifactId>
      <version>0.1-SNAPSHOT</version>
</parent>

Instead it seems to release with no problem. I can't imagine that this is a valid use case, but even if it is I would like to be able to enable this kind of checking with a config setting.

Version: 1.6.0

[LudovicPecquot]

Same problem with a multi-module project with dependency management.
The method com.amashchenko.maven.plugin.gitflow.AbstractGitFlowMojo#checkSnapshotDependencies
don't see the versions of dependencies (always null), so the allowSnapshots has no effects.

Version 1.12.0

[Opa-]

Any update on this as this could lead to release unstable versions

[glianeric]

I've made a dirty fix to take care of this; I run with 'allowSnapshots', but I've added code to the plugin to execute enforcer's requirereleasedeps rule. I'm not submitting a PR because it's a dirty change that suits my purpose for now, but in case you'd like to 'roll your own', that's the direction I chose to go in for now.

I think fixing up @aleksandr-m function is a better idea.

[user667]

Same issue, also with version 1.12.0. According to the documentation (Additional goal parameters) the expected behavior should be different:

All release goals have allowSnapshots parameter which controls whether SNAPSHOT dependencies are allowed. The default value is false (i.e. build fails if there SNAPSHOT dependency in project).

[aleksandr-m]

The allowSnapshots parameter checks only dependencies.

[glianeric]

It would be good to check the parent also. The parent in my workflow dictates versions of dependencies, so the parent itself must not be permitted to be a SNAPSHOT.
As I've mentioned, I got around this by hacking in an enforcer run, but it was a quick/dirty solution that is inserted exactly where I need it in the workflow to prevent any releases with snapshots.

[kutsal]

@aleksandr-m we have it where parent holds all <dependencyManagement> for the multi-module project. If the managed dependency is a snapshot, the plugin allows release to happen.

Parent pom snippet:

    <modules>
        <module>child1</module>
    </modules>

    <properties>
        <baz-lib.version>1.3.2-SNAPSHOT</baz-lib.version>
    </properties>

    <dependencyManagement>
        <dependencies>
            <dependency>
                <groupId>org.foo.bar</groupId>
                <artifactId>baz-lib</artifactId>
                <version>${baz-lib.version}</version>
            </dependency>
        </dependencies>
    </dependencyManagement>

Module pom snippet:

    <artifactId>child1</artifactId>

    <dependencies>
        <dependency>
            <groupId>org.foo.bar</groupId>
            <artifactId>baz-lib</artifactId>
        </dependency>
    </dependencies>

This should not be released at all.

[aleksandr-m]

@kutsal Which version you are using? If latest then please register a new issue, seems it is unrelated to this one.

BTW PR-s are welcome.

[kutsal]

@aleksandr-m We're using 1.13.0. I'm going to try with 1.14.0 and see if it happens with that version as well.

[gscokart]

I have similar issues with a simple project where the -SNAPSHOT version is defined in a properties, and the tag is using that property.

[olehpys]

Got the same issue with 1.14.0.

[user667]

I could verify that version 1.14.0 solves our issue with SNAPSHOT versions in the dependency management section.

• Releases with 1.12.0 were only failing with direct SNAPSHOT dependencies
• Releases with 1.14.0 fail with direct SNAPSHOT dependencies and SNAPSHOTs in dependency managemet (even if defined in a property) (cc @kutsal )

This issue (parent pom SNAPSHOT) is still present in 1.14.0.

[aleksandr-m]

Can someone create small test project demonstrating the case with SNAPSHOT in parent pom?

/cc @user667 @glianeric @pisarenko