[jira] [Updated] (OFBIZ-10168) Allow shutdown in Gradle without building the project

[Nicolas Malin (Jira)]

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

Karsten Tymann updated OFBIZ-10168:
-----------------------------------
    Description:
*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: GenerateVersionFile)

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.

  was:
*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: GenerateVersionFile)

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.

> 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
>            Priority: Minor
>
> *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: GenerateVersionFile)
> 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
(v7.6.3#76005)