You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@ofbiz.apache.org by "Jacques Le Roux (Jira)" <ji...@apache.org> on 2020/03/02 08:42:00 UTC
[jira] [Commented] (OFBIZ-10168) Allow shutdown in Gradle without
building the project
[ https://issues.apache.org/jira/browse/OFBIZ-10168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17048876#comment-17048876 ]
Jacques Le Roux commented on OFBIZ-10168:
-----------------------------------------
Somehow related, because it's really annoying when having multi-instances on same server, at least we face this issue in demos)
I'm not sure it would work for the demos, because the shutdown locally w/ and w/ the patch (we saw that already)
After quickly reviewing I don't think this change would help for OFBIZ-10287, but I'd like to know, so +1 for me.
> 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)