[ https://issues.apache.org/jira/browse/OFBIZ-10168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Brohl updated OFBIZ-10168:
----------------------------------
    Sprint: OFBiz Community Day (Feb 2020)

> Allow shutdown in Gradle without building the project
> -----------------------------------------------------
>
>                 Key: OFBIZ-10168
>                 URL: https://issues.apache.org/jira/browse/OFBIZ-10168
>             Project: OFBiz
>          Issue Type: Improvement
>          Components: Gradle
>    Affects Versions: Trunk
>            Reporter: Karsten Tymann
>            Assignee: Michael Brohl
>            Priority: Minor
>         Attachments: OFBIZ-10168_shutdown_without_build.patch, OFBIZ-10168_shutdown_without_build.patch
>
>
> *Allow to shutdown OFBiz server in Gradle without rebuilding the project*
> This patch for the build.gradle allows to shutdown a running OFBiz instance without
>  rebuilding the Java project. It allows for the shorter command
> {code:java}
> ./gradlew ofbizShutdown{code}
> as well as for the already known command
> {code:java}
> ./gradlew "ofbiz --shutdown".{code}
> Therefore there are no changes on the already known script calls with the addition
>  of the new shorter way "ofbizShutdown".
> "ofbizShutdown" can also be called with the portoffset parameter, passed via
> {code:java}
> ./gradlew ofbizShutdown -Pportoffset=5000{code}
> More information later.
> The reason for the patch is that a rebuilding of the project just for shutting the running instance down serves no purpose.
>  In order to run ofbiz in the background it is already compiled and therefore usable
>  for shutting it down.
>  Additionally it also makes sense to be able to shutdown ofbiz even if the current
>  changes are not compiling. Thus the shutdown does not depend on a compiling project.
> Furthermore I have changed the task definition in the method *createOfbizCommandTask*
>  since it contains a very confusing syntax. For less experienced users one might
>  think that the task dependsOn the build as well as the input *taskName-task*.
>  I changed it so that the task name is the first parameter so that it becomes
>  more clear how the task is called and on what it depends.
>  
> ------------------------------------------------------------------------------------------------------------
> Aside from the patch I want to suggest changes on the passing of the arguments for
>  future development: The passing of arguments such as "--help" or "--shutdown" is not the
>  intended way of using gradle, atleast not in the form we are doing it.
> In my opinion there are 3 accepted Gradle ways of passing arguments:
>  1. via -D -> sets a system property of the JVM
>  2. via -P -> sets a project property
>  3. via writing custom tasks that implement the @Option annotation,
>  enabling to pass arguments in the "--option=value" syntax
> While I can see that *1.* and *2.* can be tedious to implement the reading of potential arguments, I still consider it as important to implement it in either way.
>  OFBiz should not be unique in the sense of executing Gradle scripts and passing parameters
>  so the work depends on us to be as close to the Gradle-Style as possible. Technically
>  it is easy to do, again, its just a little tedious.
>  Another possibility would be to implement *3.* since it is similar to what we want to achieve.
>  The command line options can be implemented in Gradle although it is an internal feature.
>  This means that the feature is not intended for the public, although it is considered to be
>  made for public use since 2013 by the Gradle developers.
>  It allows for a great syntax of passing options to the execution of a single task:
> {code:java}
> ./gradlew exampleTask --optionName optionvalue{code}
> We can achieve such a syntax by defining a custom task:
> {code:java}
> import org.gradle.api.internal.tasks.options.Option
> task exampleTask(type: exampleTask)
> class exampleTask extends DefaultTask {
>     @Option(option = "optionName",
>             description = "Pass a parameter",
>             order = 1)
>     Object optionName
>     @TaskAction
>     void do() {
>       println optionName
>     }
> }
> {code}
> Ultimately this is the way one would wish to pass task specific options. Since
>  Gradle is using it internal, I would consider to use it as well.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)