ofbiz-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Karsten Tymann (JIRA)" <j...@apache.org>
Subject [jira] [Created] (OFBIZ-10168) Allow shutdown in Gradle without building the project
Date Wed, 17 Jan 2018 13:00:09 GMT
Karsten Tymann created OFBIZ-10168:
--------------------------------------

             Summary: 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


*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)

Mime
View raw message