Ivy
  1. Ivy
  2. IVY-1120

IvyBuildNumber non-deterministic behaviour

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.1.0-RC2
    • Fix Version/s: 2.2.0-RC1
    • Component/s: Ant
    • Labels:
      None
    • Environment:

      ant 1.7.1, windows xp

      Description

      IvyBuildNumber.java -> doExecute()

      creates an inline patternMatcher with this method:

      IvyBuildNumber.java
      
      public Matcher getMatcher(String expression) {
                      if ((expression == organisation)
                              || (expression == module)
                              || (expression == branch)) {
                          return exact.getMatcher(expression);
                      }
                      return regexp.getMatcher(expression);
                  }
      

      I'm guessing the == comparison is a typo ? Shouldn't it be saying .equals ?
      I've been having issues with this task - non-deterministic results - I got down in my debug to this place where I get wrong matcher when
      reference address comparison fails.

        Issue Links

          Activity

          Hide
          Maarten Coene added a comment -

          What attributes on ivy:buildnumber did you specify to get a wrong matcher?

          Show
          Maarten Coene added a comment - What attributes on ivy:buildnumber did you specify to get a wrong matcher?
          Hide
          Lucas Lech added a comment - - edited

          I've been running two parallel debugging sessions - the ant task that was invoking ivy:buildnumber was in first session executed directly and in another one it was executed as dependency of some other task (somewhere down the line of dependency graph) - few other ivy tasks, like ivy:publish have been executed before

          so in both sessions ivy:buildnumber has been fed with exactly the same attributes

          session invoking the ivy:buildnumber "directly" got the exact matcher while the one invoking it indirectly got the regexp one
          on both occasions expression was equal to organisation string-wise; in second session it wasn't equal address-wise though

          clearly the comparison in the matcher is broken (unless you're purposely comparing address values and I'm missing something here)
          after replacing == with .equals & rebuilding ivy, this task started working properly

          what's the reason for comparing references (ref) ant not values (*ref) ?

          Show
          Lucas Lech added a comment - - edited I've been running two parallel debugging sessions - the ant task that was invoking ivy:buildnumber was in first session executed directly and in another one it was executed as dependency of some other task (somewhere down the line of dependency graph) - few other ivy tasks, like ivy:publish have been executed before so in both sessions ivy:buildnumber has been fed with exactly the same attributes session invoking the ivy:buildnumber "directly" got the exact matcher while the one invoking it indirectly got the regexp one on both occasions expression was equal to organisation string-wise; in second session it wasn't equal address-wise though clearly the comparison in the matcher is broken (unless you're purposely comparing address values and I'm missing something here) after replacing == with .equals & rebuilding ivy, this task started working properly what's the reason for comparing references (ref) ant not values (*ref) ?
          Hide
          Maarten Coene added a comment -

          I've replaced '==' with calling the equals method in SVN trunk.

          Thanks for reporting!
          Maarten

          Show
          Maarten Coene added a comment - I've replaced '==' with calling the equals method in SVN trunk. Thanks for reporting! Maarten

            People

            • Assignee:
              Maarten Coene
              Reporter:
              Lucas Lech
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development