Grails Maven Plugin

Add a batch mode

Details

  • Type: Sub-task Sub-task
  • Status: Resolved Resolved
  • Priority: Minor Minor
  • Resolution: Fixed
  • Affects Version/s: None
  • Fix Version/s: None
  • Component/s: None
  • Labels:
    None

Description

To be able to call grails commands from another tool (an IDE, a CI server, a plugin for maven ) it's important to add a batch mode in grails. In this mode, grails mustn't ask questions if some parameters are missing, It just fail.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Graeme Rocher added a comment -

Reduced priority of non critical issues which have current workarounds

Show
Graeme Rocher added a comment - Reduced priority of non critical issues which have current workarounds
Hide
Permalink
Peter Ledbrook added a comment -

Actually, there is already a "--non-interactive" option that I have seen used in the Grails functional tests. It just needs implementing across the board.

Show
Peter Ledbrook added a comment - Actually, there is already a "--non-interactive" option that I have seen used in the Grails functional tests. It just needs implementing across the board.
Hide
Permalink
Graeme Rocher added a comment -

I've added support for a --non-interactive flag to be passed. Your script needs to depend on parseArguments and it is automatically parsed into a variable called "isInteractive". For example inside the plugin installation code we have things like:

if(!isInteractive || confirmInput("Plugin [${pluginDir.filename}] is installed, but was not found in the application's metadata, do you want to uninstall?", "confirm.${pluginDir.filename}.uninstall")) {
  uninstallPluginForName(pluginDir.filename)
}

Which just assumes you're happy with the decision if isInteractive is false. Is this ok can I close the issue now?

Show
Graeme Rocher added a comment - I've added support for a --non-interactive flag to be passed. Your script needs to depend on parseArguments and it is automatically parsed into a variable called "isInteractive". For example inside the plugin installation code we have things like: 
if(!isInteractive || confirmInput("Plugin [${pluginDir.filename}] is installed, but was not found in the application's metadata, do you want to uninstall?", "confirm.${pluginDir.filename}.uninstall")) {
  uninstallPluginForName(pluginDir.filename)
}
Which just assumes you're happy with the decision if isInteractive is false. Is this ok can I close the issue now?
Hide
Permalink
Peter Ledbrook added a comment -

I'll quickly add support for --non-interactive to GrailsScriptRunner and then close it.

Show
Peter Ledbrook added a comment - I'll quickly add support for --non-interactive to GrailsScriptRunner and then close it.
Hide
Permalink
Peter Ledbrook added a comment -

Finished it off by adding support to GrailsScriptRunner.

Show
Peter Ledbrook added a comment - Finished it off by adding support to GrailsScriptRunner.
Hide
Permalink
Arnaud Heritier added a comment -

Thanks guys. It's a good thing for continuous integration support.

Show
Arnaud Heritier added a comment - Thanks guys. It's a good thing for continuous integration support.
Hide
Permalink
Ben Tilford added a comment -

This is not supported by the either grails maven plugin or the ehcache plugin.

Trying to mvn release:perform and am unable to because it wants to know if it should overwrite the DistEhcacheConfig.groovy file.

Show
Ben Tilford added a comment - This is not supported by the either grails maven plugin or the ehcache plugin. Trying to mvn release:perform and am unable to because it wants to know if it should overwrite the DistEhcacheConfig.groovy file.

People

Vote (0)
Watch (0)

Dates

  • Created:
    Updated:
    Resolved:
Atlassian JIRA (v4.4.1#660-r161644) | Report a problem
Powered by a free Atlassian JIRA open source license for Grails project. Try JIRA - bug tracking software for your team.