3 Replies Latest reply on Apr 3, 2008 4:52 AM by Heiko Braun

    Maven Version ranges - Snapshots during development

    Adrian Brock Master

      So far I've done minimal testing of the version ranges themselves,
      but one issue I have found is that once you have a snapshot it will generally
      screw things up. I guess this is related to the bugs I linked on the other thread.

      e.g. supposing you have
      1.0.0-SNAPSHOT
      then you release
      1.0.0-Beta-2

      You would expect somebody with a constraint

      [1.0.0-Beta-3,)
      

      to have a failed build, but it will use the older snapshot instead.
      1.0.0-SNAPSHOT > 1.0.0-Beta-3

      Of course that's probably what you want when you are doing a snapshot
      after 1.0.0-Beta-3 since you then want the constraint satisifed by the snapshot.

      What's worse is that somebody with a constraint
      [1.0.0-Beta-2,)
      

      will also use the older snapshot.

      Even worse when you try to do a release it asks you if you want to
      resolve the snapshot (it thinks that is a valid version if it is in your local
      repository - the snapshot repository is of course ignored).

      So you have to zap all the snapshots from your local
      maven repository before doing releases otherwise you end up
      with something like:
      
      FIRST IT ASKS YOU IF YOU WANT TO RESOLVE THE SNAPSHOTS
      
      [INFO] Checking dependencies and plugins for snapshots ...
      There are still some remaining snapshot dependencies.: Do you want to resolve them now? (yes/no) no: : yes
      
      WHICH ONES
      
      Dependency type to resolve,: specify the selection number ( 0:All 1:Project Dependencies 2:Plugins 3:Reports 4:Extensions ): (0/1/2/3) 1: : 0
      
      THEN IT BARFS ;-)
      
      Resolve All Snapshots.: [INFO] ------------------------------------------------------------------------
      [ERROR] FATAL ERROR
      [INFO] ------------------------------------------------------------------------
      [INFO] null
      [INFO] ------------------------------------------------------------------------
      [INFO] Trace
      java.lang.NullPointerException
       at java.util.regex.Matcher.getTextLength(Matcher.java:1127)
       at java.util.regex.Matcher.reset(Matcher.java:284)
       at java.util.regex.Matcher.<init>(Matcher.java:205)
       at java.util.regex.Pattern.matcher(Pattern.java:879)
       at org.apache.maven.shared.release.versions.DefaultVersionInfo.<init>(DefaultVersionInfo.java:122)
       at org.apache.maven.shared.release.phase.CheckDependencySnapshotsPhase.processSnapshot(CheckDependencySnapshotsPhase.java:392)
       at org.apache.maven.shared.release.phase.CheckDependencySnapshotsPhase.resolveSnapshots(CheckDependencySnapshotsPhase.java:339)
       at org.apache.maven.shared.release.phase.CheckDependencySnapshotsPhase.checkProject(CheckDependencySnapshotsPhase.java:227)
       at org.apache.maven.shared.release.phase.CheckDependencySnapshotsPhase.execute(CheckDependencySnapshotsPhase.java:106)
       at org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:194)
       at org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:131)
       at org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:94)
       at org.apache.maven.plugins.release.PrepareReleaseMojo.execute(PrepareReleaseMojo.java:136)
       at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:447)
       at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539)
       at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:493)
       at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:463)
       at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311)
       at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:224)
       at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143)
       at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:333)
       at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:126)
       at org.apache.maven.cli.MavenCli.main(MavenCli.java:282)
       at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
       at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
       at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
       at java.lang.reflect.Method.invoke(Method.java:585)
       at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
       at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
       at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
       at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
      


      The handling of snapshots is definetly not ready for prime time. ;-)

        • 1. Re: Maven Version ranges - Snapshots during development
          Adrian Brock Master

          Another problem is that you can't use:

          mvn dependency:purge-local-repository -DreResolve=false

          to zap your dependencies from the local repository when there are version ranges
          in the pom.

          It simply doesn't understand the version ranges. Running it with -Dverbose=true
          just gives an non-descript "error message"
          [INFO] ------------------------------------------------------------------------
          [INFO] Building Project2
          [INFO] task-segment: [dependency:purge-local-repository] (aggregator-style)
          [INFO] ------------------------------------------------------------------------
          [INFO] [dependency:purge-local-repository]
          [INFO] Skipping: project2. It cannot be resolved.
          [INFO] Nothing to do for project: test:project2:jar:1.0.0-SNAPSHOT
          [INFO] ------------------------------------------------------------------------
          [INFO] BUILD SUCCESSFUL
          [INFO] ------------------------------------------------------------------------
          


          It doesn't even zap the dependencies that aren't version ranges.

          • 2. Re: Maven Version ranges - Snapshots during development
            Heiko Braun Master

            Taken from "BetterBuildsWithMaven":


            "Whether you use snapshots until the final release, or release betas as milestones along the way, you
            should deploy them to a snapshot repository as is discussed in Chapter 7 of this book. This will ensure
            that the beta versions are used in a range only if the project has declared the snapshot (or
            development) repository explicitly."


            • 3. Re: Maven Version ranges - Snapshots during development
              Heiko Braun Master

              If I understand the version format correctly, maven regards artifacts that contain a qualifier as snapshots anyway.
              (See my addition to the version format thread).

              This means to me, that if we switch from snapshot releases (X-SNAPSHOT) to beta milestones (X-Beta-1, X-Beta-2) instead, we should have proper dependency resolution when using version ranges.