Uploaded image for project: 'Bigtop'
  1. Bigtop
  2. BIGTOP-1948

Need to upgrade groovy-eclipse-batch as it keeps pulling from non-existing repo

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: Major
    • Resolution: Cannot Reproduce
    • Affects Version/s: 1.0.0
    • Fix Version/s: 1.1.0
    • Component/s: build
    • Labels:
      None

      Description

      Current build is trying to pull groovy-eclipse-batch from http://repository.codehaus.org/ which doesn't exist anymore.

      1. proposed.diff
        2 kB
        Olaf Flebbe
      2. BIGTOP-1948.patch
        0.8 kB
        Konstantin Boudnik
      3. BIGTOP-1948.patch
        1.0 kB
        Konstantin Boudnik

        Activity

        Hide
        cos Konstantin Boudnik added a comment -

        I haven't seen this for a long time. Perhaps the issue was transitory and caused by the transition of Groovy into new infra.

        Show
        cos Konstantin Boudnik added a comment - I haven't seen this for a long time. Perhaps the issue was transitory and caused by the transition of Groovy into new infra.
        Hide
        cos Konstantin Boudnik added a comment -

        I think your proposal is pretty much equivalent to what we have right now, except that now we'd have to change two spots instead of one whenever the version needs to be bumped, no?
        I agree about compile vs. runtime difference - perhaps we'd better bump the groovy version in the toolchain?

        Show
        cos Konstantin Boudnik added a comment - I think your proposal is pretty much equivalent to what we have right now, except that now we'd have to change two spots instead of one whenever the version needs to be bumped, no? I agree about compile vs. runtime difference - perhaps we'd better bump the groovy version in the toolchain?
        Hide
        oflebbe Olaf Flebbe added a comment -

        At least we would have a central point of versioning ....

        I guess the security fix was runtime only.... If I understand correctly the runtime and compile time aspects will be/have been modularized. So I would not recommend to hardcode a version equality between these functionalities ...

        Show
        oflebbe Olaf Flebbe added a comment - At least we would have a central point of versioning .... I guess the security fix was runtime only.... If I understand correctly the runtime and compile time aspects will be/have been modularized. So I would not recommend to hardcode a version equality between these functionalities ...
        Hide
        cos Konstantin Boudnik added a comment -

        The reason we are using groovy version for this is because in the past we used to see a huge diversion of the versions of the plugins and groovy versions all over the project. And it wasn't healthy. The reason I am trying to bump to 2.4.4 is because of the recent critical security fix in that version and because it is, finally, is the Apache release of Groovy

        Show
        cos Konstantin Boudnik added a comment - The reason we are using groovy version for this is because in the past we used to see a huge diversion of the versions of the plugins and groovy versions all over the project. And it wasn't healthy. The reason I am trying to bump to 2.4.4 is because of the recent critical security fix in that version and because it is, finally, is the Apache release of Groovy
        Hide
        oflebbe Olaf Flebbe added a comment -

        Ok, the patch accidently uses groovy 2.4.3 ... it is only a proposal

        Show
        oflebbe Olaf Flebbe added a comment - Ok, the patch accidently uses groovy 2.4.3 ... it is only a proposal
        Hide
        oflebbe Olaf Flebbe added a comment -

        I do not see the point of reusing the groovy version for the groovy-eclipse-batch version. I uploaded a proposed patch to circumvent the problem

        Show
        oflebbe Olaf Flebbe added a comment - I do not see the point of reusing the groovy version for the groovy-eclipse-batch version. I uploaded a proposed patch to circumvent the problem
        Hide
        cos Konstantin Boudnik added a comment -

        That's too: thanks. However, it seems that using 2.4.3 version still has the same issue as before (perhaps, because of the POM file on that version referring to the codehaus repo). Upgrading to 2.4.4 solve that, but then org.codehaus.groovy:groovy-eclipse-batch:jar:2.4.4-01 can not be resolved.

        Let me ask this on groovy dev@ list to see if there's a fix for this situation. In the meantime - a bit better version of the patch.

        Show
        cos Konstantin Boudnik added a comment - That's too: thanks. However, it seems that using 2.4.3 version still has the same issue as before (perhaps, because of the POM file on that version referring to the codehaus repo). Upgrading to 2.4.4 solve that, but then org.codehaus.groovy:groovy-eclipse-batch:jar:2.4.4-01 can not be resolved. Let me ask this on groovy dev@ list to see if there's a fix for this situation. In the meantime - a bit better version of the patch.
        Hide
        oflebbe Olaf Flebbe added a comment -

        Shouldn't the <groovy-eclipse-compiler.version> be increased to 2.9.2-01 as well , for the same reason?

        Show
        oflebbe Olaf Flebbe added a comment - Shouldn't the <groovy-eclipse-compiler.version> be increased to 2.9.2-01 as well , for the same reason?
        Hide
        cos Konstantin Boudnik added a comment -

        This seems to take care about the issue. Also, make sure to remove ~/.m2/repository/org/codehaus just in case

        Show
        cos Konstantin Boudnik added a comment - This seems to take care about the issue. Also, make sure to remove ~/.m2/repository/org/codehaus just in case

          People

          • Assignee:
            cos Konstantin Boudnik
            Reporter:
            cos Konstantin Boudnik
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development