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)
