[
https://issues.apache.org/jira/browse/OFBIZ-10168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Brohl reassigned OFBIZ-10168:
-------------------------------------
Assignee: Michael Brohl
> 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
>
>
> *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)
