[jira] [Commented] (OFBIZ-11359) Convert PartyContactMechServices.xml mini-lang to groovyDSL
[ https://issues.apache.org/jira/browse/OFBIZ-11359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17067977#comment-17067977 ] Olivier Heintz commented on OFBIZ-11359: After commit about this task, ContactMechServices.groovy has been move from groovyScript/party to groovyScript/contact, and modification for service definition for FTP has been forgot. So it's necessary to change in services.xml and in services_contact.xml, two lines in each for * createFtpAddress & updateFtpAddressWithHistory * createPartyFtpAddress & updatePartyFtpAddress [~nmalin] if you want I can do a patch. > Convert PartyContactMechServices.xml mini-lang to groovyDSL > --- > > Key: OFBIZ-11359 > URL: https://issues.apache.org/jira/browse/OFBIZ-11359 > Project: OFBiz > Issue Type: Sub-task > Components: party >Affects Versions: Trunk >Reporter: Nicolas Malin >Assignee: Nicolas Malin >Priority: Minor > Labels: groovy, mini-lang > Attachments: OFBIZ-11359.patch > > > Migration of file PartyContactMechServices.xml to groovy -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OFBIZ-11030) Convert FactServices.xml minilang to groovy
[ https://issues.apache.org/jira/browse/OFBIZ-11030?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17067756#comment-17067756 ] ASF subversion and git services commented on OFBIZ-11030: - Commit 492dcb9208e0daeb853bd5bd7f2499aae9afd099 in ofbiz-plugins's branch refs/heads/trunk from Jacques Le Roux [ https://gitbox.apache.org/repos/asf?p=ofbiz-plugins.git;h=492dcb9 ] Improved: fixes a typo due to OFBIZ-11030 Thanks: Pierre Smits for spotting it > Convert FactServices.xml minilang to groovy > --- > > Key: OFBIZ-11030 > URL: https://issues.apache.org/jira/browse/OFBIZ-11030 > Project: OFBiz > Issue Type: Sub-task > Components: bi >Affects Versions: Trunk >Reporter: Pierre Smits >Assignee: Michael Brohl >Priority: Major > Labels: Fact, dwh, services > Fix For: Upcoming Branch > > Attachments: OFBIZ-11030-FactServices.xml-minilang-to-groovy.patch, > OFBIZ-11030-FactServices.xml-minilang-to-groovy.patch, > OFBIZ-11030-FactServices.xml-minilang-to-groovy.patch, > OFBIZ-11030-FactServices.xml-minilang-to-groovy.patch, > OFBIZ-11030-FactServices.xml-minilang-to-groovy.patch, > OFBIZ-11030-FactServices.xml-minilang-to-groovy.patch, > OFBIZ-11030-InventoryItemFact-DemoTrunk.png, > OFBIZ-11030-InventoryItemFact-test.png, > OFBIZ-11030-Order-SalesOrder-overview.png, > OFBIZ-11030-SalesInvoiceItemFact-test.png, > OFBIZ-11030-SalesOrderItemFact-test.png, OFBIZ-11030-applyPatch-error.png > > > With the purpose to deprecate mini-lang OFBIZ-9350, convert FactServices.xml -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [ofbiz-plugins] PierreSmits edited a comment on issue #11: Improved: BI Component (OFBIZ-11414)
PierreSmits edited a comment on issue #11: Improved: BI Component (OFBIZ-11414) URL: https://github.com/apache/ofbiz-plugins/pull/11#issuecomment-603465292 Aspect no 1 should not give any problem. And then I would do the rest in a somewhat different order: 1. create a test branch from trunk, 2. rebase the PR onto the test branch, 3. test the test branch, 4. evaluate the code changes And then evaluate - if still necessary - the change from commit to commit. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Assigned] (OFBIZ-11433) Convert PartyPermissionServices.xml minilang to groovy
[ https://issues.apache.org/jira/browse/OFBIZ-11433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nicolas Malin reassigned OFBIZ-11433: - Assignee: Nicolas Malin (was: Harutyun Farajyan) > Convert PartyPermissionServices.xml minilang to groovy > -- > > Key: OFBIZ-11433 > URL: https://issues.apache.org/jira/browse/OFBIZ-11433 > Project: OFBiz > Issue Type: Sub-task > Components: accounting >Affects Versions: Trunk >Reporter: Harutyun Farajyan >Assignee: Nicolas Malin >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[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=17067603#comment-17067603
]
Jacques Le Roux commented on OFBIZ-10168:
-
OK, I should not have asked :D
> 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)
[jira] [Closed] (OFBIZ-11476) Implement the pretty print for keyword search
[ https://issues.apache.org/jira/browse/OFBIZ-11476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacques Le Roux closed OFBIZ-11476. --- Resolution: Implemented > Implement the pretty print for keyword search > - > > Key: OFBIZ-11476 > URL: https://issues.apache.org/jira/browse/OFBIZ-11476 > Project: OFBiz > Issue Type: Improvement > Components: product >Affects Versions: Trunk >Reporter: Jacques Le Roux >Assignee: Jacques Le Roux >Priority: Major > Fix For: Upcoming Branch > > > With OFBIZ-9164 and > [r1835891|https://svn.apache.org/viewvc?view=revision=1835891] I > introduced KeywordConstraint::prettyPrintConstraint without implementation. > So the information is missing at top of page. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OFBIZ-11476) Implement the pretty print for keyword search
[ https://issues.apache.org/jira/browse/OFBIZ-11476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17067560#comment-17067560 ] ASF subversion and git services commented on OFBIZ-11476: - Commit 5988e27a0d80a891f01e34a9a835ceb6a4d3119a in ofbiz-framework's branch refs/heads/trunk from Jacques Le Roux [ https://gitbox.apache.org/repos/asf?p=ofbiz-framework.git;h=5988e27 ] Improved: Implement the pretty print for keyword search (OFBIZ-11476) With OFBIZ-9164 and r1835891 I introduced keywordConstraint::prettyPrintConstraint without implementation. So the information is missing at top of page. This implements it. It also amends 2 French labels > Implement the pretty print for keyword search > - > > Key: OFBIZ-11476 > URL: https://issues.apache.org/jira/browse/OFBIZ-11476 > Project: OFBiz > Issue Type: Improvement > Components: product >Affects Versions: Trunk >Reporter: Jacques Le Roux >Assignee: Jacques Le Roux >Priority: Major > Fix For: Upcoming Branch > > > With OFBIZ-9164 and > [r1835891|https://svn.apache.org/viewvc?view=revision=1835891] I > introduced KeywordConstraint::prettyPrintConstraint without implementation. > So the information is missing at top of page. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OFBIZ-9164) Refactor ContentWorkerInterface methods signatures
[ https://issues.apache.org/jira/browse/OFBIZ-9164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17067561#comment-17067561 ] ASF subversion and git services commented on OFBIZ-9164: Commit 5988e27a0d80a891f01e34a9a835ceb6a4d3119a in ofbiz-framework's branch refs/heads/trunk from Jacques Le Roux [ https://gitbox.apache.org/repos/asf?p=ofbiz-framework.git;h=5988e27 ] Improved: Implement the pretty print for keyword search (OFBIZ-11476) With OFBIZ-9164 and r1835891 I introduced keywordConstraint::prettyPrintConstraint without implementation. So the information is missing at top of page. This implements it. It also amends 2 French labels > Refactor ContentWorkerInterface methods signatures > -- > > Key: OFBIZ-9164 > URL: https://issues.apache.org/jira/browse/OFBIZ-9164 > Project: OFBiz > Issue Type: Sub-task > Components: content, framework, lucene, order, party, product, > workeffort >Affects Versions: Trunk >Reporter: Jacques Le Roux >Assignee: Jacques Le Roux >Priority: Minor > Fix For: 17.12.01 > > Attachments: OFBIZ-9164 DataResourceWorker.java.patch, > OFBIZ-9164.patch > > > While working on OFBIZ-6919 which was built on R13.07 I stumbled upon an > issue due to r1652852 where Adrian improved the cacheKey in > FormFactory.getFormFromLocation() by adding a delegator reference (Tenants). > Actually I'm not even sure it was done at r1652852 because Adrian did not > maintain the FormFactory svn history. > Anyway, to make a long story short I had to introduce a DispatchContext > parameter when calling FormFactory.readFormDocument() when the code from > R13.07 only passed a null. > This had an impact in the hierarchy tree because > FormFactory.readFormDocument() was called in DataResourceWorker class, where > the new code was called from renderDataResourceAsText(). So I instead of only > passing a Delegator I decided to pass only a LocalDispatcher parameter in > renderDataResourceAsText(), since we can get the Delegator from the > LocalDispatcher. Doing so it had an impact on the renderDataResourceAsText > hierarchy tree ending in DataResourceWorkerInterface and all related. > I finally decided to apply the same ["Change Method Signature" refactoring > pattern|http://refactoring.com/catalog/addParameter.html] to all cases > related to ContentWorkerInterface. No need to pass a delegator when you have > LocalDispatcher! > Here I attach a patch for review, I'll commit in few days -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (OFBIZ-11476) Implement the pretty print for keyword search
[ https://issues.apache.org/jira/browse/OFBIZ-11476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacques Le Roux updated OFBIZ-11476: Description: With OFBIZ-9164 and [r1835891|https://svn.apache.org/viewvc?view=revision=1835891] I introduced KeywordConstraint::prettyPrintConstraint without implementation. So the information is missing at top of page. (was: With OFBIZ-9164 and [r1835891|https://svn.apache.org/viewvc?view=revision=1835891] I introduced a KeywordConstraint::prettyPrintConstraint without implementation. So the information is missing at top of page.) > Implement the pretty print for keyword search > - > > Key: OFBIZ-11476 > URL: https://issues.apache.org/jira/browse/OFBIZ-11476 > Project: OFBiz > Issue Type: Improvement > Components: product >Affects Versions: Trunk >Reporter: Jacques Le Roux >Assignee: Jacques Le Roux >Priority: Major > Fix For: Upcoming Branch > > > With OFBIZ-9164 and > [r1835891|https://svn.apache.org/viewvc?view=revision=1835891] I > introduced KeywordConstraint::prettyPrintConstraint without implementation. > So the information is missing at top of page. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (OFBIZ-11476) Implement the pretty print for keyword search
Jacques Le Roux created OFBIZ-11476: --- Summary: Implement the pretty print for keyword search Key: OFBIZ-11476 URL: https://issues.apache.org/jira/browse/OFBIZ-11476 Project: OFBiz Issue Type: Improvement Components: product Affects Versions: Trunk Reporter: Jacques Le Roux Assignee: Jacques Le Roux Fix For: Upcoming Branch With OFBIZ-9164 and [r1835891|https://svn.apache.org/viewvc?view=revision=1835891] I introduced a KeywordConstraint::prettyPrintConstraint without implementation. So the information is missing at top of page. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[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=17067542#comment-17067542
]
Michael Brohl commented on OFBIZ-10168:
---
I will when everything is discussed and accepted, see
[https://lists.apache.org/thread.html/rfbbddb876d20a64891da7844f002b82a603e9ad527aa60b3def62e52%40%3Cdev.ofbiz.apache.org%3E]
> 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)
[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=17067525#comment-17067525
]
Jacques Le Roux commented on OFBIZ-10168:
-
Hi Michael, will you not commit?
> 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)
