Re: Vote: move to git.
the workflow can be simple as is described in: http://www.apache.org/dev/git.html we could use this as the MVP (minimum viable product) so mimic basically how people use SVN and then slowly take advantage of the possibilities of GIT. Regards, Hans On 06/05/15 13:35, Jacopo Cappellato wrote: My vote is clearly stated: propose a Git workflow that is inline with the ASF policies and that is good for the OFBiz project and I will vote positively. Jacopo On May 6, 2015, at 8:29 AM, Hans Bakker mailingl...@antwebsystems.com wrote: Then you better change your vote? At it is now, we cannot even create an implementation proposal. Hans On 06/05/15 13:22, Jacopo Cappellato wrote: On May 6, 2015, at 3:34 AM, Hans Bakker h.bak...@antwebsystems.com wrote: It is no use, setting up an implementation plan when there is still a possibility people will reject it. Ok, if this was your goal then it seems you got your answer: most people are inclined to Git (or will not object to it) but don't feel like it is actionable enough for a vote now: defining an implementation plan, so that people can understand how the actual every day work of the OFBiz community (committers, contributors and users) with Git will be, would definitely help. Jacopo
[jira] [Created] (OFBIZ-6332) Replacing bsh code with Groovy code
Pierre Smits created OFBIZ-6332: --- Summary: Replacing bsh code with Groovy code Key: OFBIZ-6332 URL: https://issues.apache.org/jira/browse/OFBIZ-6332 Project: OFBiz Issue Type: Improvement Components: ALL APPLICATIONS Affects Versions: Trunk Reporter: Pierre Smits This is a placeholder issue to capture related issues to regarding replacing existing beanshell code with Groovy code. It helps planning and communicating. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-6271) build management with maven
[ https://issues.apache.org/jira/browse/OFBIZ-6271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14530217#comment-14530217 ] Jacques Le Roux commented on OFBIZ-6271: BTW it seems Google is going another way https://www.voxxed.com/blog/2015/05/google-layers-docker-rival-rkt-into-kubernetes/. Not sure how much of Google this means though... Anyway I guess not much of us needs Kubernetes ;) build management with maven --- Key: OFBIZ-6271 URL: https://issues.apache.org/jira/browse/OFBIZ-6271 Project: OFBiz Issue Type: Improvement Components: ALL COMPONENTS Reporter: Adam Heath Priority: Minor Attachments: console.log This is a new build system; the primary goal will be to not require any changes to existing ofbiz layouts(for backwards compatibility, at least initially). These pom.xml files are completely new; the existing build.xml infrastructure will continue to exist. The existing build.xml will never call into maven(which is what processes the pom.xml), and maven will never call into build.xml either. I have already committed a working pom.xml for the top level, and framework/start. Shortly, I will be adding framework/base and framework/entity, but into this branch. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: survey: what version(s) of gradle are available on your systems?
Hi Adam, I don't know much about Gradle and maybe I misunderstand the survey, but isn't it platform independent and can be installed in the desired version on every Java supported system? (http://gradle.org/docs/current/userguide/installation.html) Regards, Michael Brohl ecomify GmbH www.ecomify.de Am 05.05.15 um 18:42 schrieb Adam Heath: I'm considering investigating gradle, but have discovered that it's not even available for debian wheezy(nor in backports). So, I currently interested in what other people have available for installation. In jessie, the version of gradle is 1.5. smime.p7s Description: S/MIME Cryptographic Signature
Re: Vote: move to git.
On May 6, 2015, at 3:34 AM, Hans Bakker h.bak...@antwebsystems.com wrote: It is no use, setting up an implementation plan when there is still a possibility people will reject it. Ok, if this was your goal then it seems you got your answer: most people are inclined to Git (or will not object to it) but don't feel like it is actionable enough for a vote now: defining an implementation plan, so that people can understand how the actual every day work of the OFBiz community (committers, contributors and users) with Git will be, would definitely help. Jacopo
Re: Vote: move to git.
Then you better change your vote? At it is now, we cannot even create an implementation proposal. Hans On 06/05/15 13:22, Jacopo Cappellato wrote: On May 6, 2015, at 3:34 AM, Hans Bakker h.bak...@antwebsystems.com wrote: It is no use, setting up an implementation plan when there is still a possibility people will reject it. Ok, if this was your goal then it seems you got your answer: most people are inclined to Git (or will not object to it) but don't feel like it is actionable enough for a vote now: defining an implementation plan, so that people can understand how the actual every day work of the OFBiz community (committers, contributors and users) with Git will be, would definitely help. Jacopo
Re: Vote: move to git.
On May 6, 2015, at 8:56 AM, Hans Bakker mailingl...@antwebsystems.com wrote: When attached to a jira issue, then after approval (or no objection) merging the patch into the master branch by a committer so difficult? Did you read the document that you are asking us to refer to as your proposal for the firs Git MVP? The document describes a different workflow because it uses a read only Git repo: no merging on master branch will be possible. Jacopo I am sorry, i do not see a problem here Regards, Hans On 06/05/15 13:53, Jacopo Cappellato wrote: On May 6, 2015, at 8:46 AM, Hans Bakker mailingl...@antwebsystems.com wrote: the workflow can be simple as is described in: http://www.apache.org/dev/git.html we could use this as the MVP (minimum viable product) so mimic basically how people use SVN and then slowly take advantage of the possibilities of GIT. Regards, Hans Hans, I think you didn't spend enough time studying this material. The document you are referencing is what we already have: the workflow and infrastructure described are already in place: 1) a writable svn repo 2) a read only mirror in git: git://git.apache.org/ofbiz.git 3) Jira to submit patches Jacopo On 06/05/15 13:35, Jacopo Cappellato wrote: My vote is clearly stated: propose a Git workflow that is inline with the ASF policies and that is good for the OFBiz project and I will vote positively. Jacopo On May 6, 2015, at 8:29 AM, Hans Bakker mailingl...@antwebsystems.com wrote: Then you better change your vote? At it is now, we cannot even create an implementation proposal. Hans On 06/05/15 13:22, Jacopo Cappellato wrote: On May 6, 2015, at 3:34 AM, Hans Bakker h.bak...@antwebsystems.com wrote: It is no use, setting up an implementation plan when there is still a possibility people will reject it. Ok, if this was your goal then it seems you got your answer: most people are inclined to Git (or will not object to it) but don't feel like it is actionable enough for a vote now: defining an implementation plan, so that people can understand how the actual every day work of the OFBiz community (committers, contributors and users) with Git will be, would definitely help. Jacopo
Re: Vote: move to git.
On May 6, 2015, at 8:46 AM, Hans Bakker mailingl...@antwebsystems.com wrote: the workflow can be simple as is described in: http://www.apache.org/dev/git.html we could use this as the MVP (minimum viable product) so mimic basically how people use SVN and then slowly take advantage of the possibilities of GIT. Regards, Hans Hans, I think you didn't spend enough time studying this material. The document you are referencing is what we already have: the workflow and infrastructure described are already in place: 1) a writable svn repo 2) a read only mirror in git: git://git.apache.org/ofbiz.git 3) Jira to submit patches Jacopo On 06/05/15 13:35, Jacopo Cappellato wrote: My vote is clearly stated: propose a Git workflow that is inline with the ASF policies and that is good for the OFBiz project and I will vote positively. Jacopo On May 6, 2015, at 8:29 AM, Hans Bakker mailingl...@antwebsystems.com wrote: Then you better change your vote? At it is now, we cannot even create an implementation proposal. Hans On 06/05/15 13:22, Jacopo Cappellato wrote: On May 6, 2015, at 3:34 AM, Hans Bakker h.bak...@antwebsystems.com wrote: It is no use, setting up an implementation plan when there is still a possibility people will reject it. Ok, if this was your goal then it seems you got your answer: most people are inclined to Git (or will not object to it) but don't feel like it is actionable enough for a vote now: defining an implementation plan, so that people can understand how the actual every day work of the OFBiz community (committers, contributors and users) with Git will be, would definitely help. Jacopo
Re: Vote: move to git.
When attached to a jira issue, then after approval (or no objection) merging the patch into the master branch by a committer so difficult? I am sorry, i do not see a problem here Regards, Hans On 06/05/15 13:53, Jacopo Cappellato wrote: On May 6, 2015, at 8:46 AM, Hans Bakker mailingl...@antwebsystems.com wrote: the workflow can be simple as is described in: http://www.apache.org/dev/git.html we could use this as the MVP (minimum viable product) so mimic basically how people use SVN and then slowly take advantage of the possibilities of GIT. Regards, Hans Hans, I think you didn't spend enough time studying this material. The document you are referencing is what we already have: the workflow and infrastructure described are already in place: 1) a writable svn repo 2) a read only mirror in git: git://git.apache.org/ofbiz.git 3) Jira to submit patches Jacopo On 06/05/15 13:35, Jacopo Cappellato wrote: My vote is clearly stated: propose a Git workflow that is inline with the ASF policies and that is good for the OFBiz project and I will vote positively. Jacopo On May 6, 2015, at 8:29 AM, Hans Bakker mailingl...@antwebsystems.com wrote: Then you better change your vote? At it is now, we cannot even create an implementation proposal. Hans On 06/05/15 13:22, Jacopo Cappellato wrote: On May 6, 2015, at 3:34 AM, Hans Bakker h.bak...@antwebsystems.com wrote: It is no use, setting up an implementation plan when there is still a possibility people will reject it. Ok, if this was your goal then it seems you got your answer: most people are inclined to Git (or will not object to it) but don't feel like it is actionable enough for a vote now: defining an implementation plan, so that people can understand how the actual every day work of the OFBiz community (committers, contributors and users) with Git will be, would definitely help. Jacopo
Re: Vote: move to git.
On May 6, 2015, at 8:43 AM, Taher Alkhateeb slidingfilame...@gmail.com wrote: Hi Jacopo, I am a bit of a noob on ASF policies. Is it possible to guide us on resources to read to be able to draft any kind of proposal? Hi Taher, please read my previous messages on this subject because they contain some of the information you are looking for. A good document to start with could be this: http://www.apache.org/dev/writable-git and also the documents referred to it. Then also a review of the workflow adopted by other ASF project that switched to git may help to get some good ideas for OFBiz; the projects are the following: https://git-wip-us.apache.org/repos/asf By visiting their websites/wikis/mail archives we could gather useful information about their experience and lessons learned; what the ASF allows and what not. Can you also define what is an implementation plan? Is it like a document, a migration process, a commit workflow, infrastructure or what exactly? I wouldn't use the term implementation plan that was introduced by Hans: what I am asking for is essentially a description of the commit workflow proposed for OFBiz. Then we could compare it to what we have now and discuss its pros and cons. Jacopo Taher Alkhateeb On Wed, May 6, 2015 at 9:35 AM, Jacopo Cappellato jacopo.cappell...@hotwaxsystems.com wrote: My vote is clearly stated: propose a Git workflow that is inline with the ASF policies and that is good for the OFBiz project and I will vote positively. Jacopo On May 6, 2015, at 8:29 AM, Hans Bakker mailingl...@antwebsystems.com wrote: Then you better change your vote? At it is now, we cannot even create an implementation proposal. Hans On 06/05/15 13:22, Jacopo Cappellato wrote: On May 6, 2015, at 3:34 AM, Hans Bakker h.bak...@antwebsystems.com wrote: It is no use, setting up an implementation plan when there is still a possibility people will reject it. Ok, if this was your goal then it seems you got your answer: most people are inclined to Git (or will not object to it) but don't feel like it is actionable enough for a vote now: defining an implementation plan, so that people can understand how the actual every day work of the OFBiz community (committers, contributors and users) with Git will be, would definitely help. Jacopo
Re: Vote: move to git.
Ok let first wait for the vote result seeing your comment at the -1 . However then still we need a vote again after the proposal... if you make it a -0.9 then when the proposal is agreed, no need for a vote. for people who would like to help, there are plenty of GIT workflow proposals in other Apache projects. Regards, Hans On 06/05/15 14:05, Jacopo Cappellato wrote: On May 6, 2015, at 8:56 AM, Hans Bakker mailingl...@antwebsystems.com wrote: When attached to a jira issue, then after approval (or no objection) merging the patch into the master branch by a committer so difficult? Did you read the document that you are asking us to refer to as your proposal for the firs Git MVP? The document describes a different workflow because it uses a read only Git repo: no merging on master branch will be possible. Jacopo I am sorry, i do not see a problem here Regards, Hans On 06/05/15 13:53, Jacopo Cappellato wrote: On May 6, 2015, at 8:46 AM, Hans Bakker mailingl...@antwebsystems.com wrote: the workflow can be simple as is described in: http://www.apache.org/dev/git.html we could use this as the MVP (minimum viable product) so mimic basically how people use SVN and then slowly take advantage of the possibilities of GIT. Regards, Hans Hans, I think you didn't spend enough time studying this material. The document you are referencing is what we already have: the workflow and infrastructure described are already in place: 1) a writable svn repo 2) a read only mirror in git: git://git.apache.org/ofbiz.git 3) Jira to submit patches Jacopo On 06/05/15 13:35, Jacopo Cappellato wrote: My vote is clearly stated: propose a Git workflow that is inline with the ASF policies and that is good for the OFBiz project and I will vote positively. Jacopo On May 6, 2015, at 8:29 AM, Hans Bakker mailingl...@antwebsystems.com wrote: Then you better change your vote? At it is now, we cannot even create an implementation proposal. Hans On 06/05/15 13:22, Jacopo Cappellato wrote: On May 6, 2015, at 3:34 AM, Hans Bakker h.bak...@antwebsystems.com wrote: It is no use, setting up an implementation plan when there is still a possibility people will reject it. Ok, if this was your goal then it seems you got your answer: most people are inclined to Git (or will not object to it) but don't feel like it is actionable enough for a vote now: defining an implementation plan, so that people can understand how the actual every day work of the OFBiz community (committers, contributors and users) with Git will be, would definitely help. Jacopo
Re: Vote: move to git.
After creating a proper plan sure, now formally you have blocked progress with your veto. Hans On 06/05/15 14:16, Jacopo Cappellato wrote: On May 6, 2015, at 9:10 AM, Hans Bakker mailingl...@antwebsystems.com wrote: However then still we need a vote again after the proposal... if you make it a -0.9 then when the proposal is agreed, no need for a vote. are you really considering the idea of doing such an important change for the community without a clear and strong indication from it (at least a few +1 votes from his committers)? Jacopo
Re: Vote: move to git.
My vote is clearly stated: propose a Git workflow that is inline with the ASF policies and that is good for the OFBiz project and I will vote positively. Jacopo On May 6, 2015, at 8:29 AM, Hans Bakker mailingl...@antwebsystems.com wrote: Then you better change your vote? At it is now, we cannot even create an implementation proposal. Hans On 06/05/15 13:22, Jacopo Cappellato wrote: On May 6, 2015, at 3:34 AM, Hans Bakker h.bak...@antwebsystems.com wrote: It is no use, setting up an implementation plan when there is still a possibility people will reject it. Ok, if this was your goal then it seems you got your answer: most people are inclined to Git (or will not object to it) but don't feel like it is actionable enough for a vote now: defining an implementation plan, so that people can understand how the actual every day work of the OFBiz community (committers, contributors and users) with Git will be, would definitely help. Jacopo
Re: Vote: move to git.
Consensus is always needed. Best regards, Pierre Op woensdag 6 mei 2015 heeft Hans Bakker mailingl...@antwebsystems.com het volgende geschreven: Ok let first wait for the vote result seeing your comment at the -1 . However then still we need a vote again after the proposal... if you make it a -0.9 then when the proposal is agreed, no need for a vote. for people who would like to help, there are plenty of GIT workflow proposals in other Apache projects. Regards, Hans On 06/05/15 14:05, Jacopo Cappellato wrote: On May 6, 2015, at 8:56 AM, Hans Bakker mailingl...@antwebsystems.com wrote: When attached to a jira issue, then after approval (or no objection) merging the patch into the master branch by a committer so difficult? Did you read the document that you are asking us to refer to as your proposal for the firs Git MVP? The document describes a different workflow because it uses a read only Git repo: no merging on master branch will be possible. Jacopo I am sorry, i do not see a problem here Regards, Hans On 06/05/15 13:53, Jacopo Cappellato wrote: On May 6, 2015, at 8:46 AM, Hans Bakker mailingl...@antwebsystems.com wrote: the workflow can be simple as is described in: http://www.apache.org/dev/git.html we could use this as the MVP (minimum viable product) so mimic basically how people use SVN and then slowly take advantage of the possibilities of GIT. Regards, Hans Hans, I think you didn't spend enough time studying this material. The document you are referencing is what we already have: the workflow and infrastructure described are already in place: 1) a writable svn repo 2) a read only mirror in git: git://git.apache.org/ofbiz.git 3) Jira to submit patches Jacopo On 06/05/15 13:35, Jacopo Cappellato wrote: My vote is clearly stated: propose a Git workflow that is inline with the ASF policies and that is good for the OFBiz project and I will vote positively. Jacopo On May 6, 2015, at 8:29 AM, Hans Bakker mailingl...@antwebsystems.com wrote: Then you better change your vote? At it is now, we cannot even create an implementation proposal. Hans On 06/05/15 13:22, Jacopo Cappellato wrote: On May 6, 2015, at 3:34 AM, Hans Bakker h.bak...@antwebsystems.com wrote: It is no use, setting up an implementation plan when there is still a possibility people will reject it. Ok, if this was your goal then it seems you got your answer: most people are inclined to Git (or will not object to it) but don't feel like it is actionable enough for a vote now: defining an implementation plan, so that people can understand how the actual every day work of the OFBiz community (committers, contributors and users) with Git will be, would definitely help. Jacopo -- Pierre Smits *ORRTIZ.COM http://www.orrtiz.com* Services Solutions for Cloud- Based Manufacturing, Professional Services and Retail Trade http://www.orrtiz.com
Re: Vote: move to git.
On May 6, 2015, at 9:10 AM, Hans Bakker mailingl...@antwebsystems.com wrote: However then still we need a vote again after the proposal... if you make it a -0.9 then when the proposal is agreed, no need for a vote. are you really considering the idea of doing such an important change for the community without a clear and strong indication from it (at least a few +1 votes from his committers)? Jacopo
Re: Vote: move to git.
On May 6, 2015, at 9:54 AM, Hans Bakker mailingl...@antwebsystems.com wrote: After creating a proper plan sure, now formally you have blocked progress with your veto. The veto is only on commit changes, this vote is not for a commit change so my -1 doesn't count as a veto. Jacopo
Re: Vote: move to git.
Hi Jacopo, I am a bit of a noob on ASF policies. Is it possible to guide us on resources to read to be able to draft any kind of proposal? Can you also define what is an implementation plan? Is it like a document, a migration process, a commit workflow, infrastructure or what exactly? Taher Alkhateeb On Wed, May 6, 2015 at 9:35 AM, Jacopo Cappellato jacopo.cappell...@hotwaxsystems.com wrote: My vote is clearly stated: propose a Git workflow that is inline with the ASF policies and that is good for the OFBiz project and I will vote positively. Jacopo On May 6, 2015, at 8:29 AM, Hans Bakker mailingl...@antwebsystems.com wrote: Then you better change your vote? At it is now, we cannot even create an implementation proposal. Hans On 06/05/15 13:22, Jacopo Cappellato wrote: On May 6, 2015, at 3:34 AM, Hans Bakker h.bak...@antwebsystems.com wrote: It is no use, setting up an implementation plan when there is still a possibility people will reject it. Ok, if this was your goal then it seems you got your answer: most people are inclined to Git (or will not object to it) but don't feel like it is actionable enough for a vote now: defining an implementation plan, so that people can understand how the actual every day work of the OFBiz community (committers, contributors and users) with Git will be, would definitely help. Jacopo
Re: Vote: move to git.
C'mon Hans The vote was about should we convert the master SVN repository of Apache OFBIz to a GIT version? Nobody stops you from creating a proper plan. Christian Am 06.05.2015 09:54, schrieb Hans Bakker: After creating a proper plan sure, now formally you have blocked progress with your veto. Hans On 06/05/15 14:16, Jacopo Cappellato wrote: On May 6, 2015, at 9:10 AM, Hans Bakker mailingl...@antwebsystems.com wrote: However then still we need a vote again after the proposal... if you make it a -0.9 then when the proposal is agreed, no need for a vote. are you really considering the idea of doing such an important change for the community without a clear and strong indication from it (at least a few +1 votes from his committers)? Jacopo
[jira] [Updated] (OFBIZ-6329) Malfunction of configurable FTL-Template caching in DataResourceWorker.renderDataResourceAsText
[ https://issues.apache.org/jira/browse/OFBIZ-6329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Becker updated OFBIZ-6329: - Attachment: OFBIZ-6329_Non-Template-Caching-DiffOnly.patch OFBIZ-6329_FTL-Caching-DiffOnly.patch Patches *-DiffOnly.patch with simple diff format attached Malfunction of configurable FTL-Template caching in DataResourceWorker.renderDataResourceAsText --- Key: OFBIZ-6329 URL: https://issues.apache.org/jira/browse/OFBIZ-6329 Project: OFBiz Issue Type: Bug Components: content Affects Versions: Trunk Reporter: Martin Becker Attachments: OFBIZ-6329_FTL-Caching-DiffOnly.patch, OFBIZ-6329_FTL-Caching.patch, OFBIZ-6329_Non-Template-Caching-DiffOnly.patch, OFBIZ-6329_Non-Template-Caching.patch There are several problems with the current caching logic in DataResourceWorker.renderDataResourceAsText(...). Enabling the caching of rendered FTL-Templates from DataResources with the property disable.ftl.template.cache in content.properties enables a non-functioning block of code that handles the rendering of the cached template. And if it is deactivated (default), the FTL-Templates are still cached by the FreeMarkerWorker. However the correct logic for caching and using the rendered FTL-Template is already implemented in the FreeMarkerWorker and controlled by an optional useCache parameter. In addition there is an API call to DataResourceWorker.writeDataResourceText for non template content with a static true for useCache instead of using the given cache parameter value of the renderDataResourceAsText method itself, so even if the caller do not want to use caching at all, the non template text data is cached an FTL-Templates are cached also. I will provide a patch for those two issues in the mentioned method. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OFBIZ-6333) Replacing bsh code with groovy Code in MyWork screens and forms
[ https://issues.apache.org/jira/browse/OFBIZ-6333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Smits updated OFBIZ-6333: Attachment: OFBIZ-6333-BSH2Groovy-Scrum.patch This patch addresses the issue. Replacing bsh code with groovy Code in MyWork screens and forms --- Key: OFBIZ-6333 URL: https://issues.apache.org/jira/browse/OFBIZ-6333 Project: OFBiz Issue Type: Sub-task Components: specialpurpose/scrum Affects Versions: Trunk Reporter: Pierre Smits Assignee: Pierre Smits Attachments: OFBIZ-6333-BSH2Groovy-Scrum.patch -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OFBIZ-6333) Replacing bsh code with groovy Code in MyWork screens and forms
[ https://issues.apache.org/jira/browse/OFBIZ-6333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Smits updated OFBIZ-6333: Attachment: (was: OFBIZ-6333-BSH2Groovy-Scrum.patch) Replacing bsh code with groovy Code in MyWork screens and forms --- Key: OFBIZ-6333 URL: https://issues.apache.org/jira/browse/OFBIZ-6333 Project: OFBiz Issue Type: Sub-task Components: specialpurpose/scrum Affects Versions: Trunk Reporter: Pierre Smits Assignee: Pierre Smits -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OFBIZ-6334) Widget Refactoring: Have 'request-confirmation' and 'confirmation-message' available for screens and menus
Pierre Smits created OFBIZ-6334: --- Summary: Widget Refactoring: Have 'request-confirmation' and 'confirmation-message' available for screens and menus Key: OFBIZ-6334 URL: https://issues.apache.org/jira/browse/OFBIZ-6334 Project: OFBiz Issue Type: Sub-task Components: framework Reporter: Pierre Smits Currently 'request-confirmation' and 'confirmation-message' are only defined in the xsd for forms, yet they can also be applied in screen and menu links. Having it for screens and menu links improves the developer experience. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OFBIZ-6335) Replacing bsh code with groovy code in PROJECTMGR screens, forms and menus
Pierre Smits created OFBIZ-6335: --- Summary: Replacing bsh code with groovy code in PROJECTMGR screens, forms and menus Key: OFBIZ-6335 URL: https://issues.apache.org/jira/browse/OFBIZ-6335 Project: OFBiz Issue Type: Sub-task Components: specialpurpose/projectmgr Reporter: Pierre Smits -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OFBIZ-6333) Replacing bsh code with groovy Code in SCRUM screens, forms and menus
[ https://issues.apache.org/jira/browse/OFBIZ-6333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Smits updated OFBIZ-6333: Summary: Replacing bsh code with groovy Code in SCRUM screens, forms and menus (was: Replacing bsh code with groovy Code in MyWork screens and forms) Replacing bsh code with groovy Code in SCRUM screens, forms and menus - Key: OFBIZ-6333 URL: https://issues.apache.org/jira/browse/OFBIZ-6333 Project: OFBiz Issue Type: Sub-task Components: specialpurpose/scrum Affects Versions: Trunk Reporter: Pierre Smits Assignee: Pierre Smits -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OFBIZ-6333) Replacing bsh code with groovy Code in MyWork screens and forms
Pierre Smits created OFBIZ-6333: --- Summary: Replacing bsh code with groovy Code in MyWork screens and forms Key: OFBIZ-6333 URL: https://issues.apache.org/jira/browse/OFBIZ-6333 Project: OFBiz Issue Type: Sub-task Components: specialpurpose/scrum Affects Versions: Trunk Reporter: Pierre Smits -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (OFBIZ-6333) Replacing bsh code with groovy Code in MyWork screens and forms
[ https://issues.apache.org/jira/browse/OFBIZ-6333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Smits reassigned OFBIZ-6333: --- Assignee: Pierre Smits Replacing bsh code with groovy Code in MyWork screens and forms --- Key: OFBIZ-6333 URL: https://issues.apache.org/jira/browse/OFBIZ-6333 Project: OFBiz Issue Type: Sub-task Components: specialpurpose/scrum Affects Versions: Trunk Reporter: Pierre Smits Assignee: Pierre Smits -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: survey: what version(s) of gradle are available on your systems?
Gradle has to be installed before building ofbiz, so you couldn't use gradle to install gradle. And I'd prefer not to embed it directly. And custom compiling every single library that one uses day to day isn't scalable either(let's ignore gentoo). And some like to only install what is available in the stable release of whatever OS they are using. Hence the question. On 05/06/2015 05:25 AM, Michael Brohl wrote: Hi Adam, I don't know much about Gradle and maybe I misunderstand the survey, but isn't it platform independent and can be installed in the desired version on every Java supported system? (http://gradle.org/docs/current/userguide/installation.html) Regards, Michael Brohl ecomify GmbH www.ecomify.de Am 05.05.15 um 18:42 schrieb Adam Heath: I'm considering investigating gradle, but have discovered that it's not even available for debian wheezy(nor in backports). So, I currently interested in what other people have available for installation. In jessie, the version of gradle is 1.5.
Re: survey: what version(s) of gradle are available on your systems?
On May 6, 2015, at 4:45 PM, Adam Heath doo...@brainfood.com wrote: Gradle has to be installed before building ofbiz, so you couldn't use gradle to install gradle. And I'd prefer not to embed it directly. The Groovy project has some scripts for this: https://github.com/apache/incubator-groovy/blob/master/gradlew Jacopo
[jira] [Updated] (OFBIZ-6305) German translations for various applications
[ https://issues.apache.org/jira/browse/OFBIZ-6305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Becker updated OFBIZ-6305: - Attachment: OFBIZ-6305-ProductEntityLabels.patch Patch for ProductEntityLabels... German translations for various applications Key: OFBIZ-6305 URL: https://issues.apache.org/jira/browse/OFBIZ-6305 Project: OFBiz Issue Type: Improvement Components: ALL APPLICATIONS Affects Versions: Upcoming Branch Reporter: Martin Becker Assignee: Christian Geisert Attachments: OFBIZ-6305-ProductEntityLabels.patch, OFBIZ-6305-ProductErrorUiLabels.patch, OFBIZ-6305-ProductUiLabels.patch We would like to contribute missing german translations for the OFBiz applications based on the current trunk. There will arrive patches for this per application within this ticket. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-6333) Replacing bsh code with groovy Code in SCRUM screens, forms and menus
[ https://issues.apache.org/jira/browse/OFBIZ-6333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14530543#comment-14530543 ] Jacques Le Roux commented on OFBIZ-6333: I see no patch :) Replacing bsh code with groovy Code in SCRUM screens, forms and menus - Key: OFBIZ-6333 URL: https://issues.apache.org/jira/browse/OFBIZ-6333 Project: OFBiz Issue Type: Sub-task Components: specialpurpose/scrum Affects Versions: Trunk Reporter: Pierre Smits Assignee: Pierre Smits -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: svn commit: r1678076 [2/3] - in /ofbiz/trunk/applications/product/config: ProductEntityLabels.xml ProductErrorUiLabels.xml
Hehe, this has already been discussed when switching to from .properties to .xml See https://issues.apache.org/jira/browse/OFBIZ-1442 And I was against this change (with size as one argument against it) ... but meanwhile I like this format ;-) Christian Am 06.05.2015 22:57, schrieb Michael Brohl: - Posting in dev because I have no permission for commits - Yes, thought about that recently when doing the german translations. The drawback is that you have no overview about missing translations. It's easy to go through the files as they are now and add missing translations. I quick checked the size of the *UILabels.xml files, they are about 10.2 megs for all modules - not too much for today's servers with gigabytes of RAM. So I think it is not worth the effort... Michael Am 06.05.15 um 21:50 schrieb Adam Heath: Well, hmm. Nothing at all wrong with this change, but I'd like to discuss the pattern. So, the way alternative languages are implemented, is that if I am only concerned with *one* language, *all* languages have to be loaded in memory. Wouldn't it make more sense to split all these files into per-language-specific versions, so that only languages that an end-customer needs would have to be loaded into memory? Then, the name of the file ends up using the very same fallback mechanism for normal *.properties resources. On 05/06/2015 02:35 PM, chr...@apache.org wrote: Modified: ofbiz/trunk/applications/product/config/ProductEntityLabels.xml URL: http://svn.apache.org/viewvc/ofbiz/trunk/applications/product/config/ProductEntityLabels.xml?rev=1678076r1=1678075r2=1678076view=diff == --- ofbiz/trunk/applications/product/config/ProductEntityLabels.xml (original) +++ ofbiz/trunk/applications/product/config/ProductEntityLabels.xml Wed May 6 19:35:24 2015 @@ -388,6 +388,7 @@ value xml:lang=zh-TWå庫/value /property property key=GoodIdentificationType.description.GOOGLE_ID +value xml:lang=deGoogle Id/value value xml:lang=enGoogle Id/value value xml:lang=itCodice Google/value value xml:lang=jaGoogle ID/value @@ -396,6 +397,7 @@ value xml:lang=zh-TWè°·æç¨æ¶å/value /property property key=GoodIdentificationType.description.ISBN +value xml:lang=deISBN/value value xml:lang=enISBN/value value xml:lang=esISBN/value value xml:lang=frISBN/value
Re: survey: what version(s) of gradle are available on your systems?
FWIW, gradle is in Chocolatey (https://chocolatey.org/packages?q=gradle), as is groovy (https://chocolatey.org/packages?q=groovy), but neither is in NuGet. Richard. Richard Siddall wrote: Looking at our local mirror server, gradle is not available in CentOS 5, 6, or 7, or Fedora Core 21. (I assume the same is true of RedHat Enterprise Linux and the other distros derived from it.) CentOS 7 and Fedora Core 21 have (modified versions of) groovy 1.8.9. Earlier versions of CentOS do not have groovy. I did not look at EPEL or RPMForge as people have strongly held preferences about the add-on repos they will use, so requiring them to download packages from a repo they detest to build OFBiz will result in them going and looking at competing ERP systems. Last time I installed gradle, I used GVM, which will also install groovy: http://gvmtool.net/ Richard. Adam Heath wrote: Gradle has to be installed before building ofbiz, so you couldn't use gradle to install gradle. And I'd prefer not to embed it directly. And custom compiling every single library that one uses day to day isn't scalable either(let's ignore gentoo). And some like to only install what is available in the stable release of whatever OS they are using. Hence the question. On 05/06/2015 05:25 AM, Michael Brohl wrote: Hi Adam, I don't know much about Gradle and maybe I misunderstand the survey, but isn't it platform independent and can be installed in the desired version on every Java supported system? (http://gradle.org/docs/current/userguide/installation.html) Regards, Michael Brohl ecomify GmbH www.ecomify.de Am 05.05.15 um 18:42 schrieb Adam Heath: I'm considering investigating gradle, but have discovered that it's not even available for debian wheezy(nor in backports). So, I currently interested in what other people have available for installation. In jessie, the version of gradle is 1.5.
Re: svn commit: r1678076 [2/3] - in /ofbiz/trunk/applications/product/config: ProductEntityLabels.xml ProductErrorUiLabels.xml
- Posting in dev because I have no permission for commits - Yes, thought about that recently when doing the german translations. The drawback is that you have no overview about missing translations. It's easy to go through the files as they are now and add missing translations. I quick checked the size of the *UILabels.xml files, they are about 10.2 megs for all modules - not too much for today's servers with gigabytes of RAM. So I think it is not worth the effort... Michael Am 06.05.15 um 21:50 schrieb Adam Heath: Well, hmm. Nothing at all wrong with this change, but I'd like to discuss the pattern. So, the way alternative languages are implemented, is that if I am only concerned with *one* language, *all* languages have to be loaded in memory. Wouldn't it make more sense to split all these files into per-language-specific versions, so that only languages that an end-customer needs would have to be loaded into memory? Then, the name of the file ends up using the very same fallback mechanism for normal *.properties resources. On 05/06/2015 02:35 PM, chr...@apache.org wrote: Modified: ofbiz/trunk/applications/product/config/ProductEntityLabels.xml URL: http://svn.apache.org/viewvc/ofbiz/trunk/applications/product/config/ProductEntityLabels.xml?rev=1678076r1=1678075r2=1678076view=diff == --- ofbiz/trunk/applications/product/config/ProductEntityLabels.xml (original) +++ ofbiz/trunk/applications/product/config/ProductEntityLabels.xml Wed May 6 19:35:24 2015 @@ -388,6 +388,7 @@ value xml:lang=zh-TWå庫/value /property property key=GoodIdentificationType.description.GOOGLE_ID +value xml:lang=deGoogle Id/value value xml:lang=enGoogle Id/value value xml:lang=itCodice Google/value value xml:lang=jaGoogle ID/value @@ -396,6 +397,7 @@ value xml:lang=zh-TWè°·æç¨æ¶å/value /property property key=GoodIdentificationType.description.ISBN +value xml:lang=deISBN/value value xml:lang=enISBN/value value xml:lang=esISBN/value value xml:lang=frISBN/value smime.p7s Description: S/MIME Cryptographic Signature
Re: svn commit: r1678076 [2/3] - in /ofbiz/trunk/applications/product/config: ProductEntityLabels.xml ProductErrorUiLabels.xml
Except that byte site is not equal to in-memory site. Java doesn't use utf-8 internally to store character data. I believe each char is 4 bytes in size. Then you have all the extra string objects with their char array pointing into the large shared blob. On 05/06/2015 03:57 PM, Michael Brohl wrote: - Posting in dev because I have no permission for commits - Yes, thought about that recently when doing the german translations. The drawback is that you have no overview about missing translations. It's easy to go through the files as they are now and add missing translations. I quick checked the size of the *UILabels.xml files, they are about 10.2 megs for all modules - not too much for today's servers with gigabytes of RAM. So I think it is not worth the effort... Michael Am 06.05.15 um 21:50 schrieb Adam Heath: Well, hmm. Nothing at all wrong with this change, but I'd like to discuss the pattern. So, the way alternative languages are implemented, is that if I am only concerned with *one* language, *all* languages have to be loaded in memory. Wouldn't it make more sense to split all these files into per-language-specific versions, so that only languages that an end-customer needs would have to be loaded into memory? Then, the name of the file ends up using the very same fallback mechanism for normal *.properties resources. On 05/06/2015 02:35 PM, chr...@apache.org wrote: Modified: ofbiz/trunk/applications/product/config/ProductEntityLabels.xml URL: http://svn.apache.org/viewvc/ofbiz/trunk/applications/product/config/ProductEntityLabels.xml?rev=1678076r1=1678075r2=1678076view=diff == --- ofbiz/trunk/applications/product/config/ProductEntityLabels.xml (original) +++ ofbiz/trunk/applications/product/config/ProductEntityLabels.xml Wed May 6 19:35:24 2015 @@ -388,6 +388,7 @@ value xml:lang=zh-TWå庫/value /property property key=GoodIdentificationType.description.GOOGLE_ID +value xml:lang=deGoogle Id/value value xml:lang=enGoogle Id/value value xml:lang=itCodice Google/value value xml:lang=jaGoogle ID/value @@ -396,6 +397,7 @@ value xml:lang=zh-TWè°·æç¨æ¶å/value /property property key=GoodIdentificationType.description.ISBN +value xml:lang=deISBN/value value xml:lang=enISBN/value value xml:lang=esISBN/value value xml:lang=frISBN/value
buildbot success in ASF Buildbot on ofbiz-trunk
The Buildbot has detected a restored build on builder ofbiz-trunk while building ASF Buildbot. Full details are available at: http://ci.apache.org/builders/ofbiz-trunk/builds/864 Buildbot URL: http://ci.apache.org/ Buildslave for this Build: lares_ubuntu Build Reason: The AnyBranchScheduler scheduler named 'on-ofbiz-commit' triggered this build Build Source Stamp: [branch ofbiz/trunk] 1678076 Blamelist: chrisg Build succeeded! Sincerely, -The Buildbot
Re: survey: what version(s) of gradle are available on your systems?
apt-get install gradle yum install gradle emerge gradle Let's assume downloading random things that haven't been vetted against one's OS of choice is frowned upon by the powers that be at a particular company. It's a matter of not having to understand each and every single downloadable software package, and assuming that the OS developer can integrate it more properly. On 05/06/2015 10:19 AM, Taher Alkhateeb wrote: Hi Adam, Maybe I do not understand your point exactly, but I find it very trivial to install gradle with the following steps on _any_ platform: 1) Download the latest binary gradle release from their website. The current version is 2.4 2) Set $JAVA_HOME to the correct java version on your computer 3) add $GRADLE_HOME/bin to your path and enjoy! I hardly see a problem in lack of gradle release as a Debian package. It definitely exists for Ubuntu and Linux Mint which combined takes most of the linux users base. Again maybe I missed something in the thread? Taher Alkhateeb - Original Message - From: Adam Heath doo...@brainfood.com To: dev@ofbiz.apache.org Sent: Wednesday, 6 May, 2015 5:57:56 PM Subject: Re: survey: what version(s) of gradle are available on your systems? On 05/06/2015 09:52 AM, Jacopo Cappellato wrote: On May 6, 2015, at 4:45 PM, Adam Heath doo...@brainfood.com wrote: Gradle has to be installed before building ofbiz, so you couldn't use gradle to install gradle. And I'd prefer not to embed it directly. The Groovy project has some scripts for this: https://github.com/apache/incubator-groovy/blob/master/gradlew To restate, the reason I don't want maven, gradle, or ant embedded into ofbiz, is that there has been, um, issues, when it comes to using eclipse, and other tools, that *also* embed ant. On this same vein, we don't embed the approved version of the jdk into ofbiz either. With maven, gradle, and ivy, and more modern systems, the target has been to move away from embedding dependencies. It's even a best practice from ASF, as it then reduces the load on mirrors. So, take it to the logical conclusion, and don't embed the build system either.
[jira] [Commented] (OFBIZ-6305) German translations for various applications
[ https://issues.apache.org/jira/browse/OFBIZ-6305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14531268#comment-14531268 ] Christian Geisert commented on OFBIZ-6305: -- Thanks Martin! Looking forward to more contributions ;-) (I think I have a few uncomitted translations somewhere in a branch, will try to find them...) German translations for various applications Key: OFBIZ-6305 URL: https://issues.apache.org/jira/browse/OFBIZ-6305 Project: OFBiz Issue Type: Improvement Components: ALL APPLICATIONS Affects Versions: Upcoming Branch Reporter: Martin Becker Assignee: Christian Geisert Attachments: OFBIZ-6305-ProductEntityLabels.patch, OFBIZ-6305-ProductErrorUiLabels.patch, OFBIZ-6305-ProductUiLabels.patch We would like to contribute missing german translations for the OFBiz applications based on the current trunk. There will arrive patches for this per application within this ticket. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: Java 8 and functional programming in trunk
I'm favorable to use java 8. I think it's will be pretty fin if you can support oracle jdk8 and openjdk8 also. I propose to organize a vote to validate or not this proposition Nicolas Le 03/05/2015 11:52, Jacques Le Roux a écrit : Hi Taher, Yes I think so. For now well known (I hope ;)) security reasons, if people want to use Oracle JDK they need to use Java 8. So implementing with new Java 8 features now in trunk sounds good to me. BTW this is only my opinion... Note that our demos are still using OpenJDK 1.7 I'm not quite sure of the policy http://www.cvedetails.com/vulnerability-list/vendor_id-93/product_id-23642/version_id-138218/Oracle-Openjdk-1.7.0.html Jacques Le 03/05/2015 10:52, Taher Alkhateeb a écrit : Hi everyone, I would like to work on a few JIRAs and at the same refactor some existing code to utilize Lambdas and Streams utilizing Java 8 features. Is it acceptable to develop with JDK 8 features into trunk? Taher Alkhateeb
Re: svn commit: r1675852 - in /ofbiz/trunk/applications/accounting/servicedef: secas.xml secas_invoice.xml
Hi Pranay, Any chances, or is it out of subject? Jacques Le 28/04/2015 09:16, Jacques Le Roux a écrit : Hi Pranay, That's cool, but is it not worth a Jira for releases logs? Thanks Jacques Le 24/04/2015 15:29, pran...@apache.org a écrit : Author: pranayp Date: Fri Apr 24 13:29:56 2015 New Revision: 1675852 URL: http://svn.apache.org/r1675852 Log: Fixed the order in which invoice and payment transactions are created. Payment transactions were being created prior to invoice transactions, It causes confusion for accountants in real world. It was a seca execution order which was causing the issue on setInvoiceStatus. Moved the trigger on setInvoiceStatus for checkInvoicePaymentApplications and capturePaymentsByInvoice from secas.xml to secas_invoice.xml, so that we do invoice transactions prior to payment. Modified: ofbiz/trunk/applications/accounting/servicedef/secas.xml ofbiz/trunk/applications/accounting/servicedef/secas_invoice.xml Modified: ofbiz/trunk/applications/accounting/servicedef/secas.xml URL: http://svn.apache.org/viewvc/ofbiz/trunk/applications/accounting/servicedef/secas.xml?rev=1675852r1=1675851r2=1675852view=diff == --- ofbiz/trunk/applications/accounting/servicedef/secas.xml (original) +++ ofbiz/trunk/applications/accounting/servicedef/secas.xml Fri Apr 24 13:29:56 2015 @@ -158,13 +158,4 @@ under the License. condition field-name=productTypeId operator=equals value=ASSET_USAGE/ action service=createFixedAssetAndLinkToProduct mode=sync/ /eca - -eca service=setInvoiceStatus event=commit -condition field-name=invoiceId operator=is-not-empty/ -condition field-name=statusId operator=equals value=INVOICE_READY/ -condition field-name=oldStatusId operator=not-equals value=INVOICE_READY/ -condition field-name=oldStatusId operator=not-equals value=INVOICE_PAID/ -action service=checkInvoicePaymentApplications mode=sync/ -action service=capturePaymentsByInvoice mode=sync/ -/eca /service-eca Modified: ofbiz/trunk/applications/accounting/servicedef/secas_invoice.xml URL: http://svn.apache.org/viewvc/ofbiz/trunk/applications/accounting/servicedef/secas_invoice.xml?rev=1675852r1=1675851r2=1675852view=diff == --- ofbiz/trunk/applications/accounting/servicedef/secas_invoice.xml (original) +++ ofbiz/trunk/applications/accounting/servicedef/secas_invoice.xml Fri Apr 24 13:29:56 2015 @@ -47,4 +47,12 @@ under the License. action service=createMatchingPaymentApplication mode=sync/ /eca +eca service=setInvoiceStatus event=commit +condition field-name=invoiceId operator=is-not-empty/ +condition field-name=statusId operator=equals value=INVOICE_READY/ +condition field-name=oldStatusId operator=not-equals value=INVOICE_READY/ +condition field-name=oldStatusId operator=not-equals value=INVOICE_PAID/ +action service=checkInvoicePaymentApplications mode=sync/ +action service=capturePaymentsByInvoice mode=sync/ +/eca /service-eca
Re: survey: what version(s) of gradle are available on your systems?
On May 6, 2015, at 6:09 PM, Adam Heath doo...@brainfood.com wrote: That's bad too. By the way, Adam, you're as bitter as an old spinster today! :-)
Re: survey: what version(s) of gradle are available on your systems?
On 05/06/2015 10:34 AM, Jacopo Cappellato wrote: On May 6, 2015, at 4:57 PM, Adam Heath doo...@brainfood.com wrote: On 05/06/2015 09:52 AM, Jacopo Cappellato wrote: On May 6, 2015, at 4:45 PM, Adam Heath doo...@brainfood.com wrote: Gradle has to be installed before building ofbiz, so you couldn't use gradle to install gradle. And I'd prefer not to embed it directly. The Groovy project has some scripts for this: https://github.com/apache/incubator-groovy/blob/master/gradlew To restate, the reason I don't want maven, gradle, or ant embedded into ofbiz, is that there has been, um, issues, when it comes to using eclipse, and other tools, that *also* embed ant. On this same vein, we don't embed the approved version of the jdk into ofbiz either. With maven, gradle, and ivy, and more modern systems, the target has been to move away from embedding dependencies. It's even a best practice from ASF, as it then reduces the load on mirrors. So, take it to the logical conclusion, and don't embed the build system either. Groovy doesn't embed gradle, this is the reason I was pointing you to that example. Here are the notes from Groovy: == At the top directory of your unpacked source, you need to run the command: gradle This sets up the Gradle wrapper and from then on you just need the `gradlew` command instead of `gradle`. == That's bad too. So when the embedded script/docs in the checkout become invalid, due to the external location having been changed(aka, a project has to move away from codehaus, because they are out of money), then all previous versions that have already shipped will no longer work. These kind of docs should be listed separate along side the actual download/checkout process.
Re: survey: what version(s) of gradle are available on your systems?
Looking at our local mirror server, gradle is not available in CentOS 5, 6, or 7, or Fedora Core 21. (I assume the same is true of RedHat Enterprise Linux and the other distros derived from it.) CentOS 7 and Fedora Core 21 have (modified versions of) groovy 1.8.9. Earlier versions of CentOS do not have groovy. I did not look at EPEL or RPMForge as people have strongly held preferences about the add-on repos they will use, so requiring them to download packages from a repo they detest to build OFBiz will result in them going and looking at competing ERP systems. Last time I installed gradle, I used GVM, which will also install groovy: http://gvmtool.net/ Richard. Adam Heath wrote: Gradle has to be installed before building ofbiz, so you couldn't use gradle to install gradle. And I'd prefer not to embed it directly. And custom compiling every single library that one uses day to day isn't scalable either(let's ignore gentoo). And some like to only install what is available in the stable release of whatever OS they are using. Hence the question. On 05/06/2015 05:25 AM, Michael Brohl wrote: Hi Adam, I don't know much about Gradle and maybe I misunderstand the survey, but isn't it platform independent and can be installed in the desired version on every Java supported system? (http://gradle.org/docs/current/userguide/installation.html) Regards, Michael Brohl ecomify GmbH www.ecomify.de Am 05.05.15 um 18:42 schrieb Adam Heath: I'm considering investigating gradle, but have discovered that it's not even available for debian wheezy(nor in backports). So, I currently interested in what other people have available for installation. In jessie, the version of gradle is 1.5.
Re: survey: what version(s) of gradle are available on your systems?
On 05/06/2015 12:10 PM, Jacopo Cappellato wrote: On May 6, 2015, at 6:09 PM, Adam Heath doo...@brainfood.com wrote: That's bad too. By the way, Adam, you're as bitter as an old spinster today! :-) Just express issues we've had interacting with clients. It's all about placing blame. If I have to download source and compile myself, I have to take on that mantle. However, if the OS has done it, I can shift the target away from me. But placing blame sounds bad. So, let's rephrase. Random upstream pre-compiling source, may not fully understand the policies required by $chosen_OS at $company. So, use the version of $upstream already available for $chosen_OS. This is called using a support contract. I thought this was just a simple question when I asked it initially. :(
Re: Java 8 and functional programming in trunk
I'm not sure if a vote is necessary, particularly if no one has any objections. Regards Scott On 7 May 2015 07:44, Nicolas Malin nicolas.ma...@nereide.fr wrote: I'm favorable to use java 8. I think it's will be pretty fin if you can support oracle jdk8 and openjdk8 also. I propose to organize a vote to validate or not this proposition Nicolas Le 03/05/2015 11:52, Jacques Le Roux a écrit : Hi Taher, Yes I think so. For now well known (I hope ;)) security reasons, if people want to use Oracle JDK they need to use Java 8. So implementing with new Java 8 features now in trunk sounds good to me. BTW this is only my opinion... Note that our demos are still using OpenJDK 1.7 I'm not quite sure of the policy http://www.cvedetails.com/vulnerability-list/vendor_id-93/product_id-23642/version_id-138218/Oracle-Openjdk-1.7.0.html Jacques Le 03/05/2015 10:52, Taher Alkhateeb a écrit : Hi everyone, I would like to work on a few JIRAs and at the same refactor some existing code to utilize Lambdas and Streams utilizing Java 8 features. Is it acceptable to develop with JDK 8 features into trunk? Taher Alkhateeb
Re: svn commit: r1678076 [2/3] - in /ofbiz/trunk/applications/product/config: ProductEntityLabels.xml ProductErrorUiLabels.xml
To be clear: Yes, the entire file is parsed - which means it will reside in memory during parsing - but only the requested language is kept in memory. If file size becomes a problem, then we could convert to SAX parsing of UI label files. Adrian Crum Sandglass Software www.sandglass-software.com On 5/6/2015 12:50 PM, Adam Heath wrote: Well, hmm. Nothing at all wrong with this change, but I'd like to discuss the pattern. So, the way alternative languages are implemented, is that if I am only concerned with *one* language, *all* languages have to be loaded in memory. Wouldn't it make more sense to split all these files into per-language-specific versions, so that only languages that an end-customer needs would have to be loaded into memory? Then, the name of the file ends up using the very same fallback mechanism for normal *.properties resources. On 05/06/2015 02:35 PM, chr...@apache.org wrote: Modified: ofbiz/trunk/applications/product/config/ProductEntityLabels.xml URL: http://svn.apache.org/viewvc/ofbiz/trunk/applications/product/config/ProductEntityLabels.xml?rev=1678076r1=1678075r2=1678076view=diff == --- ofbiz/trunk/applications/product/config/ProductEntityLabels.xml (original) +++ ofbiz/trunk/applications/product/config/ProductEntityLabels.xml Wed May 6 19:35:24 2015 @@ -388,6 +388,7 @@ value xml:lang=zh-TWå庫/value /property property key=GoodIdentificationType.description.GOOGLE_ID +value xml:lang=deGoogle Id/value value xml:lang=enGoogle Id/value value xml:lang=itCodice Google/value value xml:lang=jaGoogle ID/value @@ -396,6 +397,7 @@ value xml:lang=zh-TWè°·æç¨æ¶å/value /property property key=GoodIdentificationType.description.ISBN +value xml:lang=deISBN/value value xml:lang=enISBN/value value xml:lang=esISBN/value value xml:lang=frISBN/value
Re: survey: what version(s) of gradle are available on your systems?
On May 6, 2015, at 4:57 PM, Adam Heath doo...@brainfood.com wrote: On 05/06/2015 09:52 AM, Jacopo Cappellato wrote: On May 6, 2015, at 4:45 PM, Adam Heath doo...@brainfood.com wrote: Gradle has to be installed before building ofbiz, so you couldn't use gradle to install gradle. And I'd prefer not to embed it directly. The Groovy project has some scripts for this: https://github.com/apache/incubator-groovy/blob/master/gradlew To restate, the reason I don't want maven, gradle, or ant embedded into ofbiz, is that there has been, um, issues, when it comes to using eclipse, and other tools, that *also* embed ant. On this same vein, we don't embed the approved version of the jdk into ofbiz either. With maven, gradle, and ivy, and more modern systems, the target has been to move away from embedding dependencies. It's even a best practice from ASF, as it then reduces the load on mirrors. So, take it to the logical conclusion, and don't embed the build system either. Groovy doesn't embed gradle, this is the reason I was pointing you to that example. Here are the notes from Groovy: == At the top directory of your unpacked source, you need to run the command: gradle This sets up the Gradle wrapper and from then on you just need the `gradlew` command instead of `gradle`. == I hope it helps, Jacopo
Re: survey: what version(s) of gradle are available on your systems?
Hi Adam, Maybe I do not understand your point exactly, but I find it very trivial to install gradle with the following steps on _any_ platform: 1) Download the latest binary gradle release from their website. The current version is 2.4 2) Set $JAVA_HOME to the correct java version on your computer 3) add $GRADLE_HOME/bin to your path and enjoy! I hardly see a problem in lack of gradle release as a Debian package. It definitely exists for Ubuntu and Linux Mint which combined takes most of the linux users base. Again maybe I missed something in the thread? Taher Alkhateeb - Original Message - From: Adam Heath doo...@brainfood.com To: dev@ofbiz.apache.org Sent: Wednesday, 6 May, 2015 5:57:56 PM Subject: Re: survey: what version(s) of gradle are available on your systems? On 05/06/2015 09:52 AM, Jacopo Cappellato wrote: On May 6, 2015, at 4:45 PM, Adam Heath doo...@brainfood.com wrote: Gradle has to be installed before building ofbiz, so you couldn't use gradle to install gradle. And I'd prefer not to embed it directly. The Groovy project has some scripts for this: https://github.com/apache/incubator-groovy/blob/master/gradlew To restate, the reason I don't want maven, gradle, or ant embedded into ofbiz, is that there has been, um, issues, when it comes to using eclipse, and other tools, that *also* embed ant. On this same vein, we don't embed the approved version of the jdk into ofbiz either. With maven, gradle, and ivy, and more modern systems, the target has been to move away from embedding dependencies. It's even a best practice from ASF, as it then reduces the load on mirrors. So, take it to the logical conclusion, and don't embed the build system either.
Re: survey: what version(s) of gradle are available on your systems?
On 05/06/2015 09:52 AM, Jacopo Cappellato wrote: On May 6, 2015, at 4:45 PM, Adam Heath doo...@brainfood.com wrote: Gradle has to be installed before building ofbiz, so you couldn't use gradle to install gradle. And I'd prefer not to embed it directly. The Groovy project has some scripts for this: https://github.com/apache/incubator-groovy/blob/master/gradlew To restate, the reason I don't want maven, gradle, or ant embedded into ofbiz, is that there has been, um, issues, when it comes to using eclipse, and other tools, that *also* embed ant. On this same vein, we don't embed the approved version of the jdk into ofbiz either. With maven, gradle, and ivy, and more modern systems, the target has been to move away from embedding dependencies. It's even a best practice from ASF, as it then reduces the load on mirrors. So, take it to the logical conclusion, and don't embed the build system either.
[jira] [Created] (OFBIZ-6336) Problem about return item in POS component
Hoan Dang Van created OFBIZ-6336: Summary: Problem about return item in POS component Key: OFBIZ-6336 URL: https://issues.apache.org/jira/browse/OFBIZ-6336 Project: OFBiz Issue Type: Bug Components: accounting, order, specialpurpose/pos Affects Versions: Trunk Reporter: Hoan Dang Van In POS component, I bought A, B product have price 50$ and 60$ respectively, then I return C product that price of it is 30$ and create order. The order has grand total is 80$. Howerver, When I check invoice of that order, I didn't saw that the C product is returned. Can everybody tell me how I solve that problem? Thanks -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: survey: what version(s) of gradle are available on your systems?
On May 6, 2015, at 5:34 PM, Jacopo Cappellato jacopo.cappell...@hotwaxsystems.com wrote: At the top directory of your unpacked source, you need to run the command: gradle This sets up the Gradle wrapper and from then on you just need the `gradlew` command instead of `gradle`. == again from Groovy readme: = To build everything using Gradle: gradlew clean dist Note: The gradlew command automatically downloads the correct Gradle version if needed, you do not need to download it first. = Jacopo
[jira] [Commented] (OFBIZ-6333) Replacing bsh code with groovy Code in SCRUM screens, forms and menus
[ https://issues.apache.org/jira/browse/OFBIZ-6333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14530785#comment-14530785 ] Pierre Smits commented on OFBIZ-6333: - That is correct. Current status is 'In progress'. I removed the patch as it was incomplete. Replacing bsh code with groovy Code in SCRUM screens, forms and menus - Key: OFBIZ-6333 URL: https://issues.apache.org/jira/browse/OFBIZ-6333 Project: OFBiz Issue Type: Sub-task Components: specialpurpose/scrum Affects Versions: Trunk Reporter: Pierre Smits Assignee: Pierre Smits -- This message was sent by Atlassian JIRA (v6.3.4#6332)
