Maven Release Plugin
  1. Maven Release Plugin
  2. MRELEASE-124

Impossible to depend on a deployed snapshot

    Details

    • Type: Bug Bug
    • Status: Closed Closed
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: 2.0-beta-4
    • Fix Version/s: 2.0-beta-7
    • Component/s: None
    • Labels:
      None
    • Number of attachments :
      4

      Description

      I have a SNAPSHOT of the war plugin that I built and deployed to fix a blocker for us (MWAR-39) that has not been released. In my POM, I refer to it like this:

      <build>
      <plugins>
      <plugin>
      <artifactId>maven-war-plugin</artifactId>
      <version>2.0.1-20060525.222101-1</version>

      I did this specifically so the release plugin would not think it was a SNAPSHOT so I could release the module. But when I do try to release, I get this error:

      [INFO] Can't release project due to non released dependencies :
      org.apache.maven.plugins:maven-war-plugin:maven-plugin:2.0.1-SNAPSHOT:runtime
      in project 'UDDI WAR' (com.webify.fabric:fabric-uddi-web:war:1.1.0-SNAPSHOT)

      This is because in ArtifactUtils.isSnapshot, it specifically disallows the version pattern created by the deploy plugin.

      So consider my usecase: I'm Joe Corporate, a user who needs a war bug fix in their build process ASAP. I build and deploy the latest war plugin to my internal repo and reference that explicit timestamp version in my build process. Now I can understand why you disallow this because if I try to build outside of our corporate walls, it will not work. But I can't use the release plugin to release either because it requires me to check the modified POMs into my SCM and the war plugin is in Apache's SCM and I can't check into it.

      There's only two hack workarounds I can think of: 1) explicitly reversion the jar to not include SNAPSHOT or the specific timestamp pattern. 2) Check the war plugin into our own SCM and release from there, effectively forking the code.

      Your thoughts? How can we fix bugs in the build process locally and still use the release plugin?

        Issue Links

          Activity

          Hide
          Brett Porter added a comment -

          I think this is still a good default behaviour (As timestamps can get removed in the future where releases are less likely to).

          However, I'd be ok with an allowTimestampedSnapshots flag.

          I'd probably suggest 1) or 2) are better solutions though. We should consider 'vendor' releases in the versioning scheme in Maven 2.1 which would make this easier.

          Show
          Brett Porter added a comment - I think this is still a good default behaviour (As timestamps can get removed in the future where releases are less likely to). However, I'd be ok with an allowTimestampedSnapshots flag. I'd probably suggest 1) or 2) are better solutions though. We should consider 'vendor' releases in the versioning scheme in Maven 2.1 which would make this easier.
          Hide
          Mike Perham added a comment -

          Interesting. I can put the timestamp build in a <pluginManagement> section of a parent POM, release that and then use it in a WAR module which can be released.

          Show
          Mike Perham added a comment - Interesting. I can put the timestamp build in a <pluginManagement> section of a parent POM, release that and then use it in a WAR module which can be released.
          Hide
          Brian Topping added a comment -

          Patch with test case for new allowTimestampedSnapshots flag.

          Show
          Brian Topping added a comment - Patch with test case for new allowTimestampedSnapshots flag.
          Hide
          Brian Topping added a comment -

          I should add this patch is against revision 465377.

          Show
          Brian Topping added a comment - I should add this patch is against revision 465377.
          Hide
          Tuomas Kiviaho added a comment -

          Patched against revision 552741

          Show
          Tuomas Kiviaho added a comment - Patched against revision 552741
          Hide
          Tuomas Kiviaho added a comment -

          John Casey has written a plugin that could automate unique versioning <http://www.commonjava.org/~jdcasey/maven-misc/plugins/snapshot-pin-maven-plugin.zip>. Blog at <http://blogs.sonatype.com/john/2007/08/14/1187117747444.html>. Wether this plugin cover parent version of pom also along with dependencies is unknown to me.

          Show
          Tuomas Kiviaho added a comment - John Casey has written a plugin that could automate unique versioning < http://www.commonjava.org/~jdcasey/maven-misc/plugins/snapshot-pin-maven-plugin.zip >. Blog at < http://blogs.sonatype.com/john/2007/08/14/1187117747444.html >. Wether this plugin cover parent version of pom also along with dependencies is unknown to me.
          Hide
          Tuomas Kiviaho added a comment -

          I noticed that issue MNG-2961 changed the behavior of artifact.isSnapshot() , but this change shouldn't have any impact since the patch didn't have to rely on the side effect in the first place.

          Show
          Tuomas Kiviaho added a comment - I noticed that issue MNG-2961 changed the behavior of artifact.isSnapshot() , but this change shouldn't have any impact since the patch didn't have to rely on the side effect in the first place.
          Hide
          Brett Porter added a comment -

          applied, thanks for that!

          Show
          Brett Porter added a comment - applied, thanks for that!

            People

            • Assignee:
              Brett Porter
              Reporter:
              Mike Perham
            • Votes:
              3 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: