Grails
  1. Grails
  2. GRAILS-4260

BuildConfig has no environment support

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Blocker Blocker
    • Resolution: Fixed
    • Affects Version/s: 1.1
    • Fix Version/s: 2.3-RC1
    • Component/s: None
    • Labels:
      None

      Description

      The BuildConfig.groovy file is loaded without an environment. This is by design because the environment is not know when it's first loaded. However, we should reload it once the environment is known.

        Activity

        Peter Ledbrook created issue -
        Graeme Rocher made changes -
        Field Original Value New Value
        Fix Version/s 1.1.2 [ 15289 ]
        Fix Version/s 1.1.1 [ 15088 ]
        Jeff Scott Brown made changes -
        Fix Version/s 1.1.2 [ 15289 ]
        Fix Version/s 1.2-M3 [ 15547 ]
        Graeme Rocher made changes -
        Fix Version/s 1.2-RC1 [ 15774 ]
        Fix Version/s 1.2-M3 [ 15547 ]
        Graeme Rocher made changes -
        Fix Version/s 1.2-M4 [ 15774 ]
        Fix Version/s 1.2-RC1 [ 15959 ]
        Hide
        Graeme Rocher added a comment -

        There is no scope / time to resolve these remaining lower priority issues for 1.2 so moving to 1.3

        for 1.2 final only issues considered blocking will now be fixed

        Show
        Graeme Rocher added a comment - There is no scope / time to resolve these remaining lower priority issues for 1.2 so moving to 1.3 for 1.2 final only issues considered blocking will now be fixed
        Graeme Rocher made changes -
        Fix Version/s 1.2-RC1 [ 15959 ]
        Fix Version/s 1.3 [ 15400 ]
        Graeme Rocher made changes -
        Fix Version/s 1.3-M1 [ 15400 ]
        Fix Version/s 1.3-RC1 [ 16274 ]
        Graeme Rocher made changes -
        Fix Version/s 1.3-RC1 [ 16274 ]
        Hide
        Greg Bridges added a comment -

        Depending on what you are trying to do, there is a workaround for this. For instance, I wanted to build the environment into my war name, so I did this:

        grails.project.war.file="MyAppName.$

        {System.getProperty('grails.env')}

        .war"

        Show
        Greg Bridges added a comment - Depending on what you are trying to do, there is a workaround for this. For instance, I wanted to build the environment into my war name, so I did this: grails.project.war.file="MyAppName.$ {System.getProperty('grails.env')} .war"
        Graeme Rocher made changes -
        Assignee Graeme Rocher [ graemerocher ]
        Hide
        Timothy Overly added a comment -

        This would be very helpful to allow for port setting in the build config depending on environment or even the db libraries.

        Show
        Timothy Overly added a comment - This would be very helpful to allow for port setting in the build config depending on environment or even the db libraries.
        Hide
        Jonathan Harlap added a comment -

        It would also be very helpful to allow for loading different sets of plugins for different environments

        Show
        Jonathan Harlap added a comment - It would also be very helpful to allow for loading different sets of plugins for different environments
        Hide
        Jan Rudert added a comment -

        Why not using

        switch (Environment.current) {
                case Environment.DEVELOPMENT:
                 //...
        }
        

        as workaround?

        Show
        Jan Rudert added a comment - Why not using switch (Environment.current) { case Environment.DEVELOPMENT: //... } as workaround?
        Hide
        Peter Ledbrook added a comment -

        The trouble is that the environment is not guaranteed to be known when the BuildConfig.groovy file is parsed. Therefore you can't rely on Environment.current being the correct environment.

        Show
        Peter Ledbrook added a comment - The trouble is that the environment is not guaranteed to be known when the BuildConfig.groovy file is parsed. Therefore you can't rely on Environment.current being the correct environment.
        Hide
        Luke Daley added a comment -

        I am sure I have seen something on the mailing list about the Dependency DSL being able to exclude plugins by environment.

        Show
        Luke Daley added a comment - I am sure I have seen something on the mailing list about the Dependency DSL being able to exclude plugins by environment.
        Hide
        Peter Ledbrook added a comment -

        Don't forget that the dependency DSL is inside a closure property and that closure is evaluated later than BuildConfig.groovy itself.

        Show
        Peter Ledbrook added a comment - Don't forget that the dependency DSL is inside a closure property and that closure is evaluated later than BuildConfig.groovy itself.
        Hide
        Malte Huebner added a comment -

        This would be very helpful to support multiple build environments - each one with different plugin dependencies (ie latest.integration, latest.release).

        Show
        Malte Huebner added a comment - This would be very helpful to support multiple build environments - each one with different plugin dependencies (ie latest.integration, latest.release).
        Hide
        Kathy Craven added a comment -

        I would like to have different web.xml base files for different environments. Currenlty I list the web.xml.tmp location in the BuildConfig. I don't want to use my tmp for Development...only test and production. So I have to manually comment/uncomment based on my environment. Looking at the gant scripts now to try and work around this.

        Show
        Kathy Craven added a comment - I would like to have different web.xml base files for different environments. Currenlty I list the web.xml.tmp location in the BuildConfig. I don't want to use my tmp for Development...only test and production. So I have to manually comment/uncomment based on my environment. Looking at the gant scripts now to try and work around this.
        Contegix Support made changes -
        Project Import Thu Mar 24 21:22:24 CDT 2011 [ 1301019744151 ]
        Burt Beckwith made changes -
        Workflow jira [ 35597 ] Grails [ 40010 ]
        Burt Beckwith made changes -
        Workflow Grails [ 40010 ] Copy of Grails [ 47444 ]
        Burt Beckwith made changes -
        Workflow Copy of Grails [ 47444 ] Grails [ 54854 ]
        Burt Beckwith made changes -
        Workflow Grails [ 54854 ] Grails2 [ 62406 ]
        Hide
        Vincent Barrier added a comment -

        I'm doing like that :

        //Workaround to detect grails environment
        def environment = Environment.getCurrent()
        
        if (environment == Environment.PRODUCTION){
            plugins {
                    println "use plugin tomcat in env:  ${environment}"
                    compile ":tomcat:1.3.7"
                }
            }else{
                plugins {
                    println "use plugin tomcatnio in env:  ${environment}"
                    compile ":tomcatnio:1.3.4"
                }
            }
        
        Show
        Vincent Barrier added a comment - I'm doing like that : //Workaround to detect grails environment def environment = Environment.getCurrent() if (environment == Environment.PRODUCTION){ plugins { println "use plugin tomcat in env: ${environment}" compile ":tomcat:1.3.7" } } else { plugins { println "use plugin tomcatnio in env: ${environment}" compile ":tomcatnio:1.3.4" } }
        Burt Beckwith made changes -
        Workflow Grails2 [ 62406 ] jira [ 71334 ]
        Burt Beckwith made changes -
        Workflow jira [ 71334 ] Grails2 [ 79583 ]
        Peter Ledbrook made changes -
        Last Reviewed 01/Jan/10
        Peter Ledbrook made changes -
        Workflow Grails2 [ 79583 ] jira [ 87702 ]
        Peter Ledbrook made changes -
        Workflow jira [ 87702 ] Grails2 [ 95889 ]
        Hide
        Rodrigo Rosenfeld Rosas added a comment -

        Any news on this issue? Will it ever be possible to specify some plugin (like console) just for my development environment?

        Show
        Rodrigo Rosenfeld Rosas added a comment - Any news on this issue? Will it ever be possible to specify some plugin (like console) just for my development environment?
        Hide
        Peter Ledbrook added a comment -

        @Rodrigo That's already possible by declaring the dependency inside an 'if (Environment.current == Environment.PRODUCTION)' condition. This issue relates to the settings outside of such closures.

        Show
        Peter Ledbrook added a comment - @Rodrigo That's already possible by declaring the dependency inside an 'if (Environment.current == Environment.PRODUCTION)' condition. This issue relates to the settings outside of such closures.
        Hide
        Pavel Vlasov added a comment -

        I was unlucky with 'Environment.current' but testing System.getProperty('grails.env') == 'production' just works for my Grails 2.2.0.

        Show
        Pavel Vlasov added a comment - I was unlucky with 'Environment.current' but testing System.getProperty('grails.env') == 'production' just works for my Grails 2.2.0.
        Hide
        Martín Caballero added a comment -

        Same case as @Pavel Vlasov in Grails 2.2.1

        Show
        Martín Caballero added a comment - Same case as @Pavel Vlasov in Grails 2.2.1
        Graeme Rocher made changes -
        Fix Version/s 2.3-RC1 [ 13458 ]
        Priority Critical [ 2 ] Blocker [ 1 ]
        Graeme Rocher made changes -
        Assignee Graeme Rocher [ graemerocher ]
        Graeme Rocher made changes -
        Status Open [ 1 ] In Progress [ 3 ]
        Graeme Rocher made changes -
        Status In Progress [ 3 ] Closed [ 6 ]
        Resolution Fixed [ 1 ]
        Hide
        Jonathan Pearlin added a comment -

        I ran into a similar issue attempting to access Environment.current in BuildConfig.groovy in Grails 2.2.3. Turns out the issue is that if you do not have an explicit import for grails.util.Environment at the top of BuildConfig.groovy, the DSL treats Environment like an empty map and therefore Environment.current resolves to [:]. Adding the import made Environment.current resolve as expected when called inside any of the DSL's in the file.

        Show
        Jonathan Pearlin added a comment - I ran into a similar issue attempting to access Environment.current in BuildConfig.groovy in Grails 2.2.3. Turns out the issue is that if you do not have an explicit import for grails.util.Environment at the top of BuildConfig.groovy , the DSL treats Environment like an empty map and therefore Environment.current resolves to [:] . Adding the import made Environment.current resolve as expected when called inside any of the DSL's in the file.

          People

          • Assignee:
            Graeme Rocher
            Reporter:
            Peter Ledbrook
          • Votes:
            36 Vote for this issue
            Watchers:
            36 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:
              Last Reviewed:

              Development