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

Plugin Allows Releases of Projects with SNAPSHOT parent POMs #64

Closed
lorkpoin opened this issue Aug 28, 2017 · 15 comments · Fixed by #323
Closed

Plugin Allows Releases of Projects with SNAPSHOT parent POMs #64

lorkpoin opened this issue Aug 28, 2017 · 15 comments · Fixed by #323

Comments

@lorkpoin
Copy link

lorkpoin commented Aug 28, 2017

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
Copy link

LudovicPecquot commented May 16, 2019

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-
Copy link

Opa- commented Aug 5, 2019

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

@glianeric
Copy link

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
Copy link

user667 commented Apr 21, 2020

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
Copy link
Owner

The allowSnapshots parameter checks only dependencies.

@glianeric
Copy link

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
Copy link

kutsal commented May 13, 2020

@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
Copy link
Owner

aleksandr-m commented May 14, 2020

@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
Copy link

kutsal commented May 16, 2020

@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
Copy link

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
Copy link

olehpys commented Jul 23, 2020

Got the same issue with 1.14.0.

@user667
Copy link

user667 commented Aug 14, 2020

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
Copy link
Owner

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

/cc @user667 @glianeric @pisarenko

@aleksandr-m aleksandr-m added the repro needed MCVE, MWE, SSCCE label Feb 4, 2021
stefanseifert added a commit to stefanseifert/gitflow-maven-plugin that referenced this issue Jan 4, 2022
…tion

add integration tests to cover SNAPSHOT dependency check
@stefanseifert
Copy link
Contributor

i've provided a PR which adds a check for SNAPSHOT version in parent POM (and also adds integration tests): #323

stefanseifert added a commit to stefanseifert/gitflow-maven-plugin that referenced this issue Jan 8, 2022
…tion

add integration tests to cover SNAPSHOT dependency check
aleksandr-m added a commit that referenced this issue Jan 8, 2022
…pshot-check

#64 Check for SNAPSHOT dependency in parent project definition
@aleksandr-m aleksandr-m removed the repro needed MCVE, MWE, SSCCE label Jan 10, 2022
@aleksandr-m
Copy link
Owner

The allowSnapshots parameter now checks dependencies and parent project.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

10 participants