Re: Strong dependency of OFBiz build on JCenter
Ahh I get it now. In that case the challenge might be making sure the naming and transitive dependencies are equivalent on both sides. Maybe another solution is to create two files, one for maven and the other for jcenter each with its own unique set of dependencies that can be tested and ensured correct behavior. This way differences in names or transitive dependencies are not an issue. On Sat, Mar 23, 2019, 5:09 PM Jacopo Cappellato < jacopo.cappell...@hotwaxsystems.com> wrote: > Just to clarify, I was suggesting that we could add more repositories, not > replace Jcenter with another one: the redundancy would mitigate the risk of > unavailability. > > Jacopo > > On Fri, Mar 22, 2019 at 6:07 PM Taher Alkhateeb < > slidingfilame...@gmail.com> > wrote: > > > Whatever repository you choose, there is always the risk of going down. > > > > To mitigate this risk, you can (after deploying the system) use the - > > -offline flag when running gradle. Alternatively you can simply run the > > java - jar command. > > > > On Fri, Mar 22, 2019, 10:41 AM Swapnil M Mane < > > swapnil.m...@hotwaxsystems.com> wrote: > > > > > Hello team, > > > > > > Yesterday JCenter was down for some time, due to which I was unable to > > > start the OFBiz server (because the build was failed). > > > Status of JCenter can be found at [1]. > > > > > > This is a severe issue because it may be possible during any production > > > deployment, JCenter is down. Do we have any solution for the issue? > > > Please let me know if I am missing anything. > > > > > > [1] https://status.bintray.com/ > > > > > > Here is stacktrace of build failure. > > > == > > > *> Task :compileTestJava* FAILED > > > > > > FAILURE: Build failed with an exception. > > > > > > * What went wrong: > > > Execution failed for task ':compileTestJava'. > > > > Could not resolve all files for configuration > ':testCompileClasspath'. > > >> Could not resolve org.mockito:mockito-core:2.+. > > > Required by: > > > project : > > > > Failed to list versions for org.mockito:mockito-core. > > > > Unable to load Maven meta-data from > > > > https://jcenter.bintray.com/org/mockito/mockito-core/maven-metadata.xml > > > < > > > > > > https://www.google.com/url?q=https://jcenter.bintray.com/org/mockito/mockito-core/maven-metadata.xml&sa=D&source=hangouts&ust=1553323118761000&usg=AFQjCNG-BdHXv5XipPli0zc2Lzk033SwEg > > > > > > > . > > > > Could not HEAD ' > > > > https://jcenter.bintray.com/org/mockito/mockito-core/maven-metadata.xml > > > < > > > > > > https://www.google.com/url?q=https://jcenter.bintray.com/org/mockito/mockito-core/maven-metadata.xml&sa=D&source=hangouts&ust=1553323118761000&usg=AFQjCNG-BdHXv5XipPli0zc2Lzk033SwEg > > > > > > > '. > > >> jcenter.bintray.com > > > > Failed to list versions for org.mockito:mockito-core. > > > > Unable to load Maven meta-data from > > > > https://jcenter.bintray.com/org/mockito/mockito-core/maven-metadata.xml > > > < > > > > > > https://www.google.com/url?q=https://jcenter.bintray.com/org/mockito/mockito-core/maven-metadata.xml&sa=D&source=hangouts&ust=1553323118761000&usg=AFQjCNG-BdHXv5XipPli0zc2Lzk033SwEg > > > > > > > . > > > > Could not HEAD ' > > > > https://jcenter.bintray.com/org/mockito/mockito-core/maven-metadata.xml > > > < > > > > > > https://www.google.com/url?q=https://jcenter.bintray.com/org/mockito/mockito-core/maven-metadata.xml&sa=D&source=hangouts&ust=1553323118761000&usg=AFQjCNG-BdHXv5XipPli0zc2Lzk033SwEg > > > > > > > '. > > >> jcenter.bintray.com > > > > > > * Try: > > > Run with *--stacktrace* option to get the stack trace. Run with > *--info* > > or > > > *--debug* option to get more log output. Run with *--scan* to get full > > > insights. > > > > > > * Get more help at *https://help.gradle.org > > > < > > > > > > https://www.google.com/url?q=https://help.gradle.org&sa=D&source=hangouts&ust=1553323118761000&usg=AFQjCNF7cVissA1Dr2SsZDCnovsUYDUE7Q > > > >* > > > > > > *BUILD FAILED* in 1m 14s > > > == > > > > > > - Best Regards, > > > Swapnil M Mane, > > > www.hotwax.co > > > > > >
Re: Strong dependency of OFBiz build on JCenter
Just to clarify, I was suggesting that we could add more repositories, not replace Jcenter with another one: the redundancy would mitigate the risk of unavailability. Jacopo On Fri, Mar 22, 2019 at 6:07 PM Taher Alkhateeb wrote: > Whatever repository you choose, there is always the risk of going down. > > To mitigate this risk, you can (after deploying the system) use the - > -offline flag when running gradle. Alternatively you can simply run the > java - jar command. > > On Fri, Mar 22, 2019, 10:41 AM Swapnil M Mane < > swapnil.m...@hotwaxsystems.com> wrote: > > > Hello team, > > > > Yesterday JCenter was down for some time, due to which I was unable to > > start the OFBiz server (because the build was failed). > > Status of JCenter can be found at [1]. > > > > This is a severe issue because it may be possible during any production > > deployment, JCenter is down. Do we have any solution for the issue? > > Please let me know if I am missing anything. > > > > [1] https://status.bintray.com/ > > > > Here is stacktrace of build failure. > > == > > *> Task :compileTestJava* FAILED > > > > FAILURE: Build failed with an exception. > > > > * What went wrong: > > Execution failed for task ':compileTestJava'. > > > Could not resolve all files for configuration ':testCompileClasspath'. > >> Could not resolve org.mockito:mockito-core:2.+. > > Required by: > > project : > > > Failed to list versions for org.mockito:mockito-core. > > > Unable to load Maven meta-data from > > https://jcenter.bintray.com/org/mockito/mockito-core/maven-metadata.xml > > < > > > https://www.google.com/url?q=https://jcenter.bintray.com/org/mockito/mockito-core/maven-metadata.xml&sa=D&source=hangouts&ust=1553323118761000&usg=AFQjCNG-BdHXv5XipPli0zc2Lzk033SwEg > > > > > . > > > Could not HEAD ' > > https://jcenter.bintray.com/org/mockito/mockito-core/maven-metadata.xml > > < > > > https://www.google.com/url?q=https://jcenter.bintray.com/org/mockito/mockito-core/maven-metadata.xml&sa=D&source=hangouts&ust=1553323118761000&usg=AFQjCNG-BdHXv5XipPli0zc2Lzk033SwEg > > > > > '. > >> jcenter.bintray.com > > > Failed to list versions for org.mockito:mockito-core. > > > Unable to load Maven meta-data from > > https://jcenter.bintray.com/org/mockito/mockito-core/maven-metadata.xml > > < > > > https://www.google.com/url?q=https://jcenter.bintray.com/org/mockito/mockito-core/maven-metadata.xml&sa=D&source=hangouts&ust=1553323118761000&usg=AFQjCNG-BdHXv5XipPli0zc2Lzk033SwEg > > > > > . > > > Could not HEAD ' > > https://jcenter.bintray.com/org/mockito/mockito-core/maven-metadata.xml > > < > > > https://www.google.com/url?q=https://jcenter.bintray.com/org/mockito/mockito-core/maven-metadata.xml&sa=D&source=hangouts&ust=1553323118761000&usg=AFQjCNG-BdHXv5XipPli0zc2Lzk033SwEg > > > > > '. > >> jcenter.bintray.com > > > > * Try: > > Run with *--stacktrace* option to get the stack trace. Run with *--info* > or > > *--debug* option to get more log output. Run with *--scan* to get full > > insights. > > > > * Get more help at *https://help.gradle.org > > < > > > https://www.google.com/url?q=https://help.gradle.org&sa=D&source=hangouts&ust=1553323118761000&usg=AFQjCNF7cVissA1Dr2SsZDCnovsUYDUE7Q > > >* > > > > *BUILD FAILED* in 1m 14s > > == > > > > - Best Regards, > > Swapnil M Mane, > > www.hotwax.co > > >
Re: svn commit: r1855798 - /ofbiz/ofbiz-framework/trunk/build.gradle
Ah forgot we have that pending also: https://cwiki.apache.org/confluence/display/OFBIZ/Guidelines+For+Using+JIRA Le 23/03/2019 à 11:59, Jacques Le Roux a écrit : Hi Mathieu, Le 20/03/2019 à 22:19, Mathieu Lirzin a écrit : I must confess that the policy regarding how refactoring (done by committers) must be handled in term of JIRA creation, is not clear to me. The block “When to create a Jira issue” on OFBiz wiki [1] is not helping much in that regard. Maybe there is an implicit consensus in that regard that I am not aware of? My reasoning for not creating a JIRA was that those commits are pure refactoring meaning they are implementation details that don't change the observable behavior of the build and they are not part of a global plan. Basically those cleanups happened by looking around while working on OFBIZ-10866 [2] but are unrelated to the endeavour of that task. What would you recommend in that scenario? I don't remember that we discussed specifically about Jira and refactoring (with no functional changes, which is the implicit definition of refactoring). At least we did not write about it. One thing I do for very simple no functional changes (not only for refactoring) is to use this syntax in commits comments : Improved: no functional change Explanations... When the changes are considerable (which is subjective, it's hard to set a line) I create a Jira and explain the changes. We could write something about that in the wiki section “When to create a Jira issue” which is quite old and has not been reviewed for a long time. Rest that it will always be subjective, we can say that. The same idea applies to Javadoc changes: big one a Jira, simple one no Jira. It's a matter of judgement, when it take much more time to create a Jira than to only explain in a commit comment for instance. The changes you did (from r1855674 to r1855798) did not hurt me. I just reviewed again and for me none of them need more explanations than in the commits. Now, the fact that there was 9 commits in a row could be interpreted as a substantial change and maybe explains Michael's perspective. Then maybe a Jira referring to these commits with a summary in description could help reassuring users about these changes. Both (Jira or not) fits with me in this case. My 2cts Jacques
Re: svn commit: r1855798 - /ofbiz/ofbiz-framework/trunk/build.gradle
Hi Mathieu, Le 20/03/2019 à 22:19, Mathieu Lirzin a écrit : I must confess that the policy regarding how refactoring (done by committers) must be handled in term of JIRA creation, is not clear to me. The block “When to create a Jira issue” on OFBiz wiki [1] is not helping much in that regard. Maybe there is an implicit consensus in that regard that I am not aware of? My reasoning for not creating a JIRA was that those commits are pure refactoring meaning they are implementation details that don't change the observable behavior of the build and they are not part of a global plan. Basically those cleanups happened by looking around while working on OFBIZ-10866 [2] but are unrelated to the endeavour of that task. What would you recommend in that scenario? I don't remember that we discussed specifically about Jira and refactoring (with no functional changes, which is the implicit definition of refactoring). At least we did not write about it. One thing I do for very simple no functional changes (not only for refactoring) is to use this syntax in commits comments : Improved: no functional change Explanations... When the changes are considerable (which is subjective, it's hard to set a line) I create a Jira and explain the changes. We could write something about that in the wiki section “When to create a Jira issue” which is quite old and has not been reviewed for a long time. Rest that it will always be subjective, we can say that. The same idea applies to Javadoc changes: big one a Jira, simple one no Jira. It's a matter of judgement, when it take much more time to create a Jira than to only explain in a commit comment for instance. The changes you did (from r1855674 to r1855798) did not hurt me. I just reviewed again and for me none of them need more explanations than in the commits. Now, the fact that there was 9 commits in a row could be interpreted as a substantial change and maybe explains Michael's perspective. Then maybe a Jira referring to these commits with a summary in description could help reassuring users about these changes. Both (Jira or not) fits with me in this case. My 2cts Jacques
Defining multi-segment routes in the controller.
Hello, To continue the work previously done on providing a REST-like API [1] directly inside the controller DSL. We need to support routes with multiple segments like in the following example: … … … The problems is that multiple-segment paths have already some semantics attached to it. Here are the ones I am aware of: - *overridden view URI* is a feature which consists in dynamically redefining the view that must be rendered by a route for example if a browser sends a request with the path “/earth/moon” the request map with ‘uri’ attribute “earth” will run and the view whose name is “moon” will be rendered. - *Query parameters inside the path* is a feature defining an alternative way to pass query parameters, meaning the part following the path like in the following example "/earth/moon?foo=1&bar=2" where we have the path "/earth/moon" followed by two query parameters “foo” and “bar” which are respectively associated with the values 1 and 2. With the query parameter inside the path feature the path “/earth/moon/~foo=1/~bar=2” will have the same interpretation as the previous one in OFBiz. Those features needs to be adapted/removed in order to properly support multi-segment routes. The overridden view could be superseeded with URI templates [2] like in the following example: The query parameters in the path feature can simply be removed since we don't need an alternative way to define query parameters. Artemiy Rozovyk which is starting an internship at Nereide on Monday will be working on that topic under my supervision. Please step in if the analysis I have made here is incomplete or is overlooking any edge case. Thanks. [1] https://issues.apache.org/jira/browse/OFBIZ-4274 [2] https://tools.ietf.org/html/rfc6570 -- Mathieu Lirzin GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37
