groovy
  1. groovy
  2. GROOVY-2422

API for checking version and capabilities of Groovy runtime

    Details

    • Type: Wish Wish
    • Status: Open Open
    • Priority: Minor Minor
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None
    • Environment:
      All
    • Number of attachments :
      0

      Description

      As discussed on the groovy-user mailing list, the idea here is to provide a simple API for checking/asserting the Groovy version that a script is being run under or the "capabilities" it provides. This would allow scripts to ensure that the environment they are running in is able to support their needs and to either halt execution or recover gracefully.

      A potential API would look something like this:

      package groovy.lang
      
      class GroovyRuntime {
          /* Capability checks */
          static void registerCapability(String capability, String description)
      
          static boolean hasCapability(String... capability)
      
          static void assertCapability(String... capability) throws AssertionError
      
          /* Version checks */
          static boolean hasMinimumVersion(String version)
      
          static void assertMinimumVersion(String version) throws AssertionError
      
          static boolean hasVersionInRange(String minVersion, String maxVersion)
      
          static void assertVersionInRange(String minVersion, String maxVersion) throws AssertionError
      }
      

      The version checks would have enough smarts about the Groovy versioning scheme to be able to know about "beta", "rc", and "SNAPSHOT" in addition to standard version string comparison logic. For what it's worth, Perl has similar functionality (e.g. "use v5.8"). The capability checking mechanism would allow capabilities to be registered with a code and description and would allow capabilities to be checked by code. Capabilities would correspond to major features like "joint-compilation", "annotations", "enumerations", etc.

        Activity

        Hide
        Guillaume Laforge added a comment -

        Being able to do something like that at the top of a script could be handy:

        ensure minVersion: '1.5.1'
        ensure has: 'joint-compiler'
        ensure has: ['generics', 'annotations']

        Show
        Guillaume Laforge added a comment - Being able to do something like that at the top of a script could be handy: ensure minVersion: '1.5.1' ensure has: 'joint-compiler' ensure has: ['generics', 'annotations']
        Hide
        Paul King added a comment -

        I think a survey of what other languages/systems do would be good.
        Some questions which spring to mind:

        • Is 'joint-compiler' a property of the language, the compiler,etc?
        • What about 'properties' of modules?
        • Rather than just "ensure minVersion: '1.5.1'" can we just give a warning if a min version isn't met?
        Show
        Paul King added a comment - I think a survey of what other languages/systems do would be good. Some questions which spring to mind: Is 'joint-compiler' a property of the language, the compiler,etc? What about 'properties' of modules? Rather than just " ensure minVersion: '1.5.1' " can we just give a warning if a min version isn't met?
        Hide
        Guillaume Laforge added a comment -

        I was thinking just about the general Groovy features, including language features or tooling.
        But perhaps it's just interesting for language features per se.

        Regarding module, it'd mean modules should be able to provide their own properties?
        We need to create and add to the roadmap a GEP on modularity, and it would probably a topic to discuss if we want to provide such version / feature checking capabilities.

        Show
        Guillaume Laforge added a comment - I was thinking just about the general Groovy features, including language features or tooling. But perhaps it's just interesting for language features per se. Regarding module, it'd mean modules should be able to provide their own properties? We need to create and add to the roadmap a GEP on modularity, and it would probably a topic to discuss if we want to provide such version / feature checking capabilities.
        Hide
        Guillaume Laforge added a comment -

        GROOVY-3884 is also related to that issue, as a special ReleaseInfo class has been added in 1.6/1.7/1.8
        With Groovy 1.8 upcoming modularity, we may also think about this "capability" idea some more.
        At least providing a way to programmatically know whether a certain Groovy module is present or not, if not providing real capabilities support with a super fine-grained approach.

        Show
        Guillaume Laforge added a comment - GROOVY-3884 is also related to that issue, as a special ReleaseInfo class has been added in 1.6/1.7/1.8 With Groovy 1.8 upcoming modularity, we may also think about this "capability" idea some more. At least providing a way to programmatically know whether a certain Groovy module is present or not, if not providing real capabilities support with a super fine-grained approach.
        Hide
        Guillaume Laforge added a comment - - edited

        For reference, the current page about Groovy 1.9 modularization:
        http://docs.codehaus.org/display/GROOVY/Groovy+1.9+modularization
        I've added a section in that document mentioning this issue.

        Show
        Guillaume Laforge added a comment - - edited For reference, the current page about Groovy 1.9 modularization: http://docs.codehaus.org/display/GROOVY/Groovy+1.9+modularization I've added a section in that document mentioning this issue.

          People

          • Assignee:
            Unassigned
            Reporter:
            Mike Dillon
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated: