Re: [jira] [Commented] (OFBIZ-5522) Introduce websocket usage
FYI: I have sent a request to remove the spammer user at https://issues.apache.org/jira/servicedesk/customer/portal/1/create/3 Jacques Le 21/04/2015 05:46, sourabh gupta (JIRA) a écrit : [ https://issues.apache.org/jira/browse/OFBIZ-5522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14504248#comment-14504248 ] sourabh gupta commented on OFBIZ-5522: -- http://6packersandmovers.in/packers-and-movers-ahmedabad/ http://6packersandmovers.in/packers-and-movers-surat/ http://6packersandmovers.in/packers-and-movers-rajkot/ http://6packersandmovers.in/packers-and-movers-vadodara/ Introduce websocket usage - Key: OFBIZ-5522 URL: https://issues.apache.org/jira/browse/OFBIZ-5522 Project: OFBiz Issue Type: Task Components: framework Affects Versions: Trunk Reporter: Jacques Le Roux Priority: Minor After a discussion with Ean, was suggested (draft here): You need a service that lets you subscribe a widget to an entity and then propagate change events to the widget as the entity is modified. A generic mechanism like that could eventually expand to be a general purpose data bound widgets system that mostly looks like the existing system but magically reflects updates. Could be used with/for * The entity cache and webforms to automatically update views when data changes. * Replaces the current system notes * Create a dashboard type pages (to be discussed futher) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: move to git.
Quoting: We are also prepared to be assertive regarding this situation. If the project does not move to GIT then Brainfood is willing to participate in a consortium of organizations that will peer with each other to share updates to the master branch for their local OFBiz repository. Such an arrangement will, effectively, result in a distributed master repository image. Thanks Ean for the position of *Brainfood* in this position. It comes across as 'Do it our way, or else'. You are free to make such statements and when followed through there will be consequences. For all participating in this project. One I can see standing out clearly is: no more participation in/contribution from the employees of Brainfood and from the other companies in that consortium back into the project. If that is going to happen, I will say: 'I thank you for all the contributions you did to the project'. And I will check in my sentiments at the door. I do hope that if you do you also resign totally from this project. I rather have the community comes to its decision based on sound/valid arguments, not (veiled) threats. Best regards, Pierre Smits *ORRTIZ.COM http://www.orrtiz.com* Services Solutions for Cloud- Based Manufacturing, Professional Services and Retail Trade http://www.orrtiz.com On Tue, Apr 21, 2015 at 2:08 AM, Ean Schuessler e...@brainfood.com wrote: - Original Message - From: Jacques Le Roux jacques.le.r...@les7arts.com Subject: Re: move to git. Like Adrian and mostly for the same reasons, I don't believe we need Git. But there is one other major reason which has already been discussed in the other common ASF MLs. As Taher exulted, it's possible to create local branches. So people are able to do a lot of work alone without exchanging before committing or submitting. It will certainly not help to have this possibility. I disagree. It is useful in many situations for OFBiz developers to create a local repository that is not globally shared. Some customers may even require such a situation for security or legal reasons. Remember our recent discussion on the lack or core commits reviews. With Git you end with commits bursts or big patches and it's then hard to review and too late to share ideas. So unlike Adrian, I'm even strongly against it. I will not hesitate to use a -1 if necessary! We are also prepared to be assertive regarding this situation. If the project does not move to GIT then Brainfood is willing to participate in a consortium of organizations that will peer with each other to share updates to the master branch for their local OFBiz repository. Such an arrangement will, effectively, result in a distributed master repository image. If anyone else is interested in such an arrangement please feel free to speak up and we can begin the planning process.
Re: discussion: Move to Maven was:Re: svn commit: r1674216 - in /ofbiz/trunk: framework/start/pom.xml pom.xml
Quoting: pps: I did a comparison of ant, ivy, maven, and gradle at http://trends.google.com/. Maven is the correct choice, gradle is too new. Ohh. Then we could just as well wait and sit it out to see another 'winner' rising to the top? Following the fad (http://en.wikipedia.org/wiki/Fad) is a good argument? I dare to say: not! Best regards, Pierre Smits *ORRTIZ.COM http://www.orrtiz.com* Services Solutions for Cloud- Based Manufacturing, Professional Services and Retail Trade http://www.orrtiz.com On Tue, Apr 21, 2015 at 12:33 AM, Adam Heath doo...@brainfood.com wrote: (picking a random email to respond to; I haven't read anything of this thread all weekend, I will need to spend some time doing so) Fyi, I have framework/start, base, and entity all compiling with maven now. API test cases work. Separate foo.jar and foo-test.jar are done. META-INF/services/ all located properly. Everything in base/lib/** and entity/lib/** has dependency settings in pom.xml, but *without* having to download anything(yet). I can't stress enough that there are *no* changes to any existing files. Absolutely none. As such, due to the volume of this discussion, I will be coming up with a way to have all these poms overlayed(or some other technical solution) to an unmodified ofbiz checkout. Git submodules might not be the right approach, I need to look at git subtree a bit more. ps: It's suprising how quickly I was able to start getting maven to work. I thought it would be extremely difficult. pps: I did a comparison of ant, ivy, maven, and gradle at http://trends.google.com/. Maven is the correct choice, gradle is too new. On 04/20/2015 01:43 PM, Pierre Smits wrote: Assumptions are the Mother of all Fuckups, is often said. Nevertheless, bringing all viewpoints and insights together (without the assumptions and/or coloured projections) will lead to a better informed community, enabling it to take the right decision. Best regards, Pierre Smits *ORRTIZ.COM http://www.orrtiz.com* Services Solutions for Cloud- Based Manufacturing, Professional Services and Retail Trade http://www.orrtiz.com On Mon, Apr 20, 2015 at 8:31 PM, Ron Wheeler rwhee...@artifact-software.com wrote: Sorry Pierre. I hope it did not not ruin your evening. I guess old tools are like old homes. Hard to say goodbye even if the new house fits your needs better. (Assuming that the consensus is that Ant needs replacing) Ron On 20/04/2015 2:17 PM, Pierre Smits wrote: Thanks for sharing the viewpoints. I could (just barely) suppress a physical reaction when I read 'Getting rid of ant is a good thing regardless'. Luckily we implement changes based on consensus, not the preference of the few. Best regards, Pierre Smits *ORRTIZ.COM http://www.orrtiz.com* Services Solutions for Cloud- Based Manufacturing, Professional Services and Retail Trade http://www.orrtiz.com On Mon, Apr 20, 2015 at 8:00 PM, Ron Wheeler rwhee...@artifact-software.com wrote: Maven imposes a philosophy on builds that you either follow or fight (and lose). The good side is that once you have your structure and supporting processes in place anyone who knows a little bit of Maven can run a build without looking at the pom and can add a dependency without destroying the build. You can build plug-ins to encapsulate best practices or to accomplish tasks that are not part of the software build. It is still possible to misuse Maven but it takes a lot of work and there is an active community to help avoid doing silly things. It is also actively supported with regular new versions so bug fixes and enhancement do get released quickly. I have used Maven for years and like it a lot. Gradle is new and getting a lot of attention so it might be a better choice but I have never used it. Flexibility is nice until some bad practices get put into a build process to solve a problem quickly rather than well. I love Ant and use it for other things but as a build tool it is too flexible and does not impose any structure or Best Practices. It also is an additional step on the learning curve which acts as a barrier to attracting developers; specially younger members who have been using more modern tools. Getting rid of Ant is a good thing regardless of where you go. Ron On 20/04/2015 1:25 PM, Jacopo Cappellato wrote: Some of the build files are really ugly at the moment and difficult to read: see the macros.xml, src-extra-set etc... The ability to write real code snippets may greatly simplify them. Jacopo On Apr 20, 2015, at 7:00 PM, David E. Jones d...@me.com wrote: That gets back to the question of why change in the first place... build files may be smaller and easier to maintain, but there may not be a good reason! -David On 20 Apr 2015, at 09:37, Pierre Smits pierre.sm...@gmail.com wrote: David, Thanks for sharing your insights. You talk about
[jira] [Commented] (OFBIZ-6267) Replace ProductionRun.fo with widgets
[ https://issues.apache.org/jira/browse/OFBIZ-6267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14504643#comment-14504643 ] Pierre Smits commented on OFBIZ-6267: - Of course it can be done. It just takes (a bit more) effort. The question it leads to is: is one willing? Replace ProductionRun.fo with widgets - Key: OFBIZ-6267 URL: https://issues.apache.org/jira/browse/OFBIZ-6267 Project: OFBiz Issue Type: Improvement Components: manufacturing Reporter: Christian Carlow Assignee: Nicolas Malin -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: Discussion: Replace framework by Moqui.
@Nicolas: The questions you raise are vaild. And ever present. Each will find his/her own justification for the choice made. This project is not about that. It offers a choice, based on a shared vision. Best regards Pierre Smits *ORRTIZ.COM http://www.orrtiz.com* Services Solutions for Cloud- Based Manufacturing, Professional Services and Retail Trade http://www.orrtiz.com On Tue, Apr 21, 2015 at 9:48 AM, Nicolas Malin nicolas.ma...@nereide.fr wrote: Le 20/04/2015 22:27, Pierre Smits a écrit : @Nicolas: in the end it is code change. Does your point of view reflect a veto? If the code change and the backward compatibility is present, no worries. We are an enterprise automation software not just a framework. Many companies trust in this stability and it's the main reason that I love OFBiz. I think we are relatively smart to don't break it ;) If I don't need backward compatibility without making customer project directly with Moqui/mantle, why keep Apache OFBiz ? Best regards, Pierre Smits *ORRTIZ.COM http://www.orrtiz.com* Services Solutions for Cloud- Based Manufacturing, Professional Services and Retail Trade http://www.orrtiz.com On Mon, Apr 20, 2015 at 10:23 PM, Nicolas Malin nicolas.ma...@nereide.fr wrote: We have to be aware that every project (proprietary or Open Source) somewhere in the lifespan faces the moment of breaking backwards compatibility of their products. Even today there are still some products whose owners had to walk that walk and survived But that is more about the trustworthiness of the owner/project. And even then it were hard walks Moqui is very attractive, at this time I think it will be embed in OFBiz framework and not replace it. Because it's important to have the backward compatibility (java interface, and xml model reader can be used to make sure it). It's the OFBiz strong ! My point of view is : no backward compatibility, no discussion :) Nicolas Best regards, Pierre Smits *ORRTIZ.COM http://www.orrtiz.com* Services Solutions for Cloud- Based Manufacturing, Professional Services and Retail Trade http://www.orrtiz.com On Mon, Apr 20, 2015 at 8:39 PM, David E. Jones d...@me.com wrote: On 19 Apr 2015, at 22:31, Hans Bakker mailingl...@antwebsystems.com wrote: Again, as discussed at the ApacheCon in Austin we should start setting up a plan how to best move the ERP application to the Moqui framework. Moqui should not be part of the Apache foundation however the ERP application should remain there. Not only will it improve development of the ERP system but also will establish a clean separation between application and frameworks and hopefully getting David Jones back into the project. Yes, I realize i open the pandora box :-) but we need to make some major decisions I'll write this general reply with my OFBiz hat on, not my Moqui one. For Moqui Framework being used by OFBiz would be fantastic. It would bring a lot of well needed use and attention to the project and get it to a level that would take much longer with the current pace of growth. The growth is increasing, but it's nothing like the early years of OFBiz when the marketplace was so different... at that time OFBiz was unique as there weren't many feature-rich open source ecommerce or ERP systems, especially not in Java! I still find it amazing that OFBiz took off as much as it did... I was 23 years old when I started it, and only had 2 years of full-time development work behind me, and only 1 year of that was on ecommerce and ERP systems. Andrew had more experience with custom ecommerce development, but mostly in Perl IIRC. Anyway, enough nostalgia, back to the present. Using Moqui Framework in OFBiz would involve some really significant changes. The Moqui API is much cleaner (and everything is available through the single ExecutionContext class), but much different from the scattered static classes of the OFBiz framework. It may be possible to refactor much of the code with some regex search/replace wizardry, but there is a LOT of code in OFBiz to change. The data model and to some extent service definitions would be easy. I have some FTL templates for transforming those that I'd be happy to share (they are in a private repo right now). I used these to create the little Moqui component that has the OFBiz data model from version 10.04 which I used with a client to run a sort of OFBiz/Moqui hybrid. On that note... if anyone wants to experiment with this that might be a good place to start: get the latest data model definitions in a Moqui component, deploy the Moqui WAR in the same servlet container as OFBiz (just drop it in an OFBiz component) and then run them in parallel accessing the same DB and play with migrating a few screens/etc. IMO the biggest questions/concerns should be: 1. the significant effort required to do the migration 2. the impact on
Re: move to git.
Hi All I've been looking at some of what OFBiz France has done regarding addons for OFBiz . I think there are a lot of useful things that have been contributed by the community in general (not only OFBiz France) that are either sitting in forks or addons or just in Jira that haven't really been visible to the community. Making them visible gives the community more freedom and choice - whatever tool is used. Thanks Sharan On 21.4.2015 12:19, Jacques Le Roux wrote: Le 21/04/2015 12:02, David E. Jones a écrit : On 20 Apr 2015, at 23:21, Pierre Smits pierre.sm...@gmail.com wrote: Quoting: We are also prepared to be assertive regarding this situation. If the project does not move to GIT then Brainfood is willing to participate in a consortium of organizations that will peer with each other to share updates to the master branch for their local OFBiz repository. Such an arrangement will, effectively, result in a distributed master repository image. Thanks Ean for the position of *Brainfood* in this position. It comes across as 'Do it our way, or else'. You are free to make such statements and when followed through there will be consequences. For all participating in this project. One I can see standing out clearly is: no more participation in/contribution from the employees of Brainfood and from the other companies in that consortium back into the project. That's not at all what I get from Ean's comments. The magic of a community-driven project is that people can collaborate on anything they want, within the scope of the main project or as side projects. If the main project doesn't provide something desired, then it is perfectly appropriate for others to collaborate on that... better than doing it totally isolated. What Ean is talking about ties in with the general idea of distributed source management and distributed development. The general idea is that there may be many forks of the main source repo, potentially with various branches for different improvements and changes. These are generally made available publicly, like public GitHub forks of other public repositories (though with git they can be hosted anywhere). Those who make changes can request that particular changes be pulled into upstream repositories and then those who maintain the upstream repos (or the main project repo if it bubbles up that high) can review them and pull the changes if desired. Those who maintain upstream repos can also look around for useful changes in forked repos and pull them in as desired. Others who run their own forks can pull in changes from peer repositories too. It may seem like chaos to have forks and changes spread all over the place... but that isn't caused by the distributed source management approach, it's just made visible and clear by the approach. Right now this exists on a large scale for OFBiz, tons of forks and changes in them, but they are mostly not visible or publicly available so there is no way for OFBiz committers to pull changes from other repos... they basically have to be extracted into a patch file and submitted through a Jira issue. In other words, the chaos exists and the distributed source management enabled by git just makes it easier to track it all and tame it a bit. On a side note, this is one of the reasons I have concerns about making Moqui and related projects part of the ASF: the ASF community approach doesn't fit very well with this distributed source management model (pull requests are discouraged, all contributions should go through Jira issues... though I don't know that this is a strict policy). -David Interesting David, it can be compared to the OFBiz-France association effort to leverage the Nereides addons and addons manager. I let aside the licenses issues, as long as it's no part of a released package there are no problems. What do you think OFBiz-France members? Jacques If that is going to happen, I will say: 'I thank you for all the contributions you did to the project'. And I will check in my sentiments at the door. I do hope that if you do you also resign totally from this project. I rather have the community comes to its decision based on sound/valid arguments, not (veiled) threats. Best regards, Pierre Smits *ORRTIZ.COM http://www.orrtiz.com* Services Solutions for Cloud- Based Manufacturing, Professional Services and Retail Trade http://www.orrtiz.com On Tue, Apr 21, 2015 at 2:08 AM, Ean Schuessler e...@brainfood.com wrote: - Original Message - From: Jacques Le Roux jacques.le.r...@les7arts.com Subject: Re: move to git. Like Adrian and mostly for the same reasons, I don't believe we need Git. But there is one other major reason which has already been discussed in the other common ASF MLs. As Taher exulted, it's possible to create local branches. So people are able to do a lot of work alone without exchanging before committing or submitting. It will certainly
Re: move to git.
Sharing those improvements as patches attached to JIRA issues is a way better mechanism for exposure and review than through the distributed and competing search/find tools of today (Google et all) into all the distributed repositories or forks. Best regards, Pierre. Op dinsdag 21 april 2015 heeft Sharan Foga sharan.f...@gmail.com het volgende geschreven: Hi All I've been looking at some of what OFBiz France has done regarding addons for OFBiz . I think there are a lot of useful things that have been contributed by the community in general (not only OFBiz France) that are either sitting in forks or addons or just in Jira that haven't really been visible to the community. Making them visible gives the community more freedom and choice - whatever tool is used. Thanks Sharan On 21.4.2015 12:19, Jacques Le Roux wrote: Le 21/04/2015 12:02, David E. Jones a écrit : On 20 Apr 2015, at 23:21, Pierre Smits pierre.sm...@gmail.com wrote: Quoting: We are also prepared to be assertive regarding this situation. If the project does not move to GIT then Brainfood is willing to participate in a consortium of organizations that will peer with each other to share updates to the master branch for their local OFBiz repository. Such an arrangement will, effectively, result in a distributed master repository image. Thanks Ean for the position of *Brainfood* in this position. It comes across as 'Do it our way, or else'. You are free to make such statements and when followed through there will be consequences. For all participating in this project. One I can see standing out clearly is: no more participation in/contribution from the employees of Brainfood and from the other companies in that consortium back into the project. That's not at all what I get from Ean's comments. The magic of a community-driven project is that people can collaborate on anything they want, within the scope of the main project or as side projects. If the main project doesn't provide something desired, then it is perfectly appropriate for others to collaborate on that... better than doing it totally isolated. What Ean is talking about ties in with the general idea of distributed source management and distributed development. The general idea is that there may be many forks of the main source repo, potentially with various branches for different improvements and changes. These are generally made available publicly, like public GitHub forks of other public repositories (though with git they can be hosted anywhere). Those who make changes can request that particular changes be pulled into upstream repositories and then those who maintain the upstream repos (or the main project repo if it bubbles up that high) can review them and pull the changes if desired. Those who maintain upstream repos can also look around for useful changes in forked repos and pull them in as desired. Others who run their own forks can pull in changes from peer repositories too. It may seem like chaos to have forks and changes spread all over the place... but that isn't caused by the distributed source management approach, it's just made visible and clear by the approach. Right now this exists on a large scale for OFBiz, tons of forks and changes in them, but they are mostly not visible or publicly available so there is no way for OFBiz committers to pull changes from other repos... they basically have to be extracted into a patch file and submitted through a Jira issue. In other words, the chaos exists and the distributed source management enabled by git just makes it easier to track it all and tame it a bit. On a side note, this is one of the reasons I have concerns about making Moqui and related projects part of the ASF: the ASF community approach doesn't fit very well with this distributed source management model (pull requests are discouraged, all contributions should go through Jira issues... though I don't know that this is a strict policy). -David Interesting David, it can be compared to the OFBiz-France association effort to leverage the Nereides addons and addons manager. I let aside the licenses issues, as long as it's no part of a released package there are no problems. What do you think OFBiz-France members? Jacques If that is going to happen, I will say: 'I thank you for all the contributions you did to the project'. And I will check in my sentiments at the door. I do hope that if you do you also resign totally from this project. I rather have the community comes to its decision based on sound/valid arguments, not (veiled) threats. Best regards, Pierre Smits *ORRTIZ.COM http://www.orrtiz.com* Services Solutions for Cloud- Based Manufacturing, Professional Services and Retail Trade http://www.orrtiz.com On Tue, Apr 21, 2015 at 2:08 AM, Ean Schuessler e...@brainfood.com wrote: - Original Message - From: Jacques Le Roux
Re: Discussion: Replace framework by Moqui.
Yes, in the past many also have claimed that that Dinosaur would be extinct in the short future... I can relate to the other priorities and constraints. Should you be in the position: there might be an OFBiz track again at ACEU15 in Budapest later this year. Though I am not sure regarding the certainty of that. Directions at another level have changed... Best regards, Pierre Smits *ORRTIZ.COM http://www.orrtiz.com* Services Solutions for Cloud- Based Manufacturing, Professional Services and Retail Trade http://www.orrtiz.com On Tue, Apr 21, 2015 at 12:12 PM, David E. Jones d...@me.com wrote: Fascinating diagram in that link from The Economist. I had no idea IBM had such huge market share in the past! It's good to see the industry becoming more distributed, ie market share spread across a larger number of companies. Thanks, nice to be engaged in the project here and there. No, I wasn't at ApacheCon last week, a bit outside my current budgets (both time and money), especially with competing priorities like visiting family and friends... which I'm sure is the case for many would have liked to attend. -David On 21 Apr 2015, at 01:12, Pierre Smits pierre.sm...@gmail.com wrote: Nice to have you back and engaged, David. My apologies if I didn't express that earlier. Were you at ACNA15 also? Best regards, Pierre Smits *ORRTIZ.COM http://www.orrtiz.com* Services Solutions for Cloud- Based Manufacturing, Professional Services and Retail Trade http://www.orrtiz.com On Tue, Apr 21, 2015 at 8:59 AM, Pierre Smits pierre.sm...@gmail.com wrote: Quoting: I suspect that the world is heading to git. I am just starting to get acquanted with it and beginning to feel like a bit of a dinosaur using SVN for our projects internally. That should be in another thread. Nevertheless, such can be said regarding a lot of (also unrelated) subjects/things which are still happily used by a great number. See the 'dinosaur' in this: http://cdn.static-economist.com/sites/default/files/imagecache/original-size/images/print-edition/20150404_WBC737_0.png Best regards, Pierre Smits *ORRTIZ.COM http://www.orrtiz.com* Services Solutions for Cloud- Based Manufacturing, Professional Services and Retail Trade http://www.orrtiz.com On Tue, Apr 21, 2015 at 3:43 AM, Ron Wheeler rwhee...@artifact-software.com wrote: On 20/04/2015 5:07 PM, David E. Jones wrote: On 20 Apr 2015, at 12:48, Ron Wheeler rwhee...@artifact-software.com wrote: On 20/04/2015 3:11 PM, David E. Jones wrote: On 20 Apr 2015, at 11:35, Ron Wheeler rwhee...@artifact-software.com wrote: Would Moqui become a sub-project of OFBiz with distinct deliverable with an Apache license? Or is that too much community? IMO they are better as distinct projects. There is a chance Moqui Framework could become a separate ASF project, though the name Apache Moqui is oddly contradictory (I chose the name based on Moqui Marbles, but it is also another name for the Hopi tribe). More seriously, these days I like the distributed and moderated approaches used in the Linux kernel more than the community approach mandated by the ASF. What would be the problem of it being part of OFBiz in the same way that FOP and Batik are part of the XLMGraphics project or Jetspeed is part of the Portals project. A lot less work than a TLP but still benefiting from Apache. Would not have to call of Apache Moqui. It would just be Moqui , part of Apache OfBiz XML Graphics and Portals are both umbrella projects, meant to have sub-projects, and OFBiz is not. OFBiz could be restructured that way, and perhaps even have sub-projects without that restructuring sort of like the Jackrabbit Oak project, but still not sure if it makes sense. On that note: if a Moqui-based (or Moqui and Mantle based) version of OFBiz were built it might make sense as a sub-project just like Oak is of Jackrabbit. On a far side note: Oak looks great but I wish it ran on something other than MongoDB so it could be embedded for dev and smaller deployments! The process of becoming a TLP isn't that much of a concern to me. It takes time, but is worth it to establish a firm foundation for the project going forward. The main issues that concern me are the various and changing policies of the ASF. I have a hard time seeing the point of trademarks for open source projects, for example. Not sure if this is key to the current discussion but I would not mind hearing details of your concerns since we have put a bit of an effort into that area recently. The community model is another concern, I don't like the structure as much as certain alternatives in the open source world (even if I used to think it was the best approach, or at least something similar to the ASF approach). It may be possible to manage a more distributed
Interesting resources about the code of conduct in our open source community
Hi all, I would like to share with you some non-technical but useful documents: 1) the first one is the Code of Conduct @ the ASF: it is a document that I always keep open in my browser in order to minimize the risk of forgetting some of its points while discussing heated topics :-) http://apache.org/foundation/policies/conduct.html 2) the second is a video recording of one of the keynotes of ApacheCon 2015 @ Austin: How to Thoroughly Insult and Offend People in Your Open Source Communities: https://www.youtube.com/watch?v=rOWmrlft2FI Regards, Jacopo
Re: move to git.
Le 21/04/2015 02:08, Ean Schuessler a écrit : - Original Message - From: Jacques Le Roux jacques.le.r...@les7arts.com Subject: Re: move to git. Like Adrian and mostly for the same reasons, I don't believe we need Git. But there is one other major reason which has already been discussed in the other common ASF MLs. As Taher exulted, it's possible to create local branches. So people are able to do a lot of work alone without exchanging before committing or submitting. It will certainly not help to have this possibility. I disagree. It is useful in many situations for OFBiz developers to create a local repository that is not globally shared. What about https://github.com/apache/ofbiz ? Some customers may even require such a situation for security or legal reasons. People can do what they want with OFBiz code on their side, sharing with the community is something else (and often harder) Jacques Remember our recent discussion on the lack or core commits reviews. With Git you end with commits bursts or big patches and it's then hard to review and too late to share ideas. So unlike Adrian, I'm even strongly against it. I will not hesitate to use a -1 if necessary! We are also prepared to be assertive regarding this situation. If the project does not move to GIT then Brainfood is willing to participate in a consortium of organizations that will peer with each other to share updates to the master branch for their local OFBiz repository. Such an arrangement will, effectively, result in a distributed master repository image. If anyone else is interested in such an arrangement please feel free to speak up and we can begin the planning process.
[jira] [Updated] (OFBIZ-5917) Improve the way FOP handles fonts notably for currency symbols
[ https://issues.apache.org/jira/browse/OFBIZ-5917?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacques Le Roux updated OFBIZ-5917: --- Fix Version/s: Upcoming Branch I have improved a bit more, for examples, at revision: 1675061 Improve the way FOP handles fonts notably for currency symbols -- Key: OFBIZ-5917 URL: https://issues.apache.org/jira/browse/OFBIZ-5917 Project: OFBiz Issue Type: Improvement Components: framework Affects Versions: Trunk Reporter: Jacques Le Roux Assignee: Jacques Le Roux Priority: Minor Labels: rupee, symbol Fix For: 14.12.01, Upcoming Branch In the dev ML I suggested we could add auto-detect/ in the fonts section of our fop.xconf We can do more than that. For instance currently there are no easy ways to render the new (since 2010) rupee symbol: ₹. One is to use the Google NotoSans font which is Apache licensed * http://www.google.com/fonts/specimen/Noto+Sans * https://www.google.com/get/noto/#/ We need also to * Add the rupee symbol (₹) to antisamy-esapi.xml file like we have the euro symbol (€) * Use NotoSans as the default FOP font. For that we can put the NotoSans font 4 files in framework/resources/fonts and add directoryframework/resources/fonts/NotoSansFonts/directory in our fop.xconf * Render ₹ in content/control/fonts.pdf as we do for €. Other symbols could be added later when needed, backed by Google NotoSans font... -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: Discussion: Replace framework by Moqui.
Nice to have you back and engaged, David. My apologies if I didn't express that earlier. Were you at ACNA15 also? Best regards, Pierre Smits *ORRTIZ.COM http://www.orrtiz.com* Services Solutions for Cloud- Based Manufacturing, Professional Services and Retail Trade http://www.orrtiz.com On Tue, Apr 21, 2015 at 8:59 AM, Pierre Smits pierre.sm...@gmail.com wrote: Quoting: I suspect that the world is heading to git. I am just starting to get acquanted with it and beginning to feel like a bit of a dinosaur using SVN for our projects internally. That should be in another thread. Nevertheless, such can be said regarding a lot of (also unrelated) subjects/things which are still happily used by a great number. See the 'dinosaur' in this: http://cdn.static-economist.com/sites/default/files/imagecache/original-size/images/print-edition/20150404_WBC737_0.png Best regards, Pierre Smits *ORRTIZ.COM http://www.orrtiz.com* Services Solutions for Cloud- Based Manufacturing, Professional Services and Retail Trade http://www.orrtiz.com On Tue, Apr 21, 2015 at 3:43 AM, Ron Wheeler rwhee...@artifact-software.com wrote: On 20/04/2015 5:07 PM, David E. Jones wrote: On 20 Apr 2015, at 12:48, Ron Wheeler rwhee...@artifact-software.com wrote: On 20/04/2015 3:11 PM, David E. Jones wrote: On 20 Apr 2015, at 11:35, Ron Wheeler rwhee...@artifact-software.com wrote: Would Moqui become a sub-project of OFBiz with distinct deliverable with an Apache license? Or is that too much community? IMO they are better as distinct projects. There is a chance Moqui Framework could become a separate ASF project, though the name Apache Moqui is oddly contradictory (I chose the name based on Moqui Marbles, but it is also another name for the Hopi tribe). More seriously, these days I like the distributed and moderated approaches used in the Linux kernel more than the community approach mandated by the ASF. What would be the problem of it being part of OFBiz in the same way that FOP and Batik are part of the XLMGraphics project or Jetspeed is part of the Portals project. A lot less work than a TLP but still benefiting from Apache. Would not have to call of Apache Moqui. It would just be Moqui , part of Apache OfBiz XML Graphics and Portals are both umbrella projects, meant to have sub-projects, and OFBiz is not. OFBiz could be restructured that way, and perhaps even have sub-projects without that restructuring sort of like the Jackrabbit Oak project, but still not sure if it makes sense. On that note: if a Moqui-based (or Moqui and Mantle based) version of OFBiz were built it might make sense as a sub-project just like Oak is of Jackrabbit. On a far side note: Oak looks great but I wish it ran on something other than MongoDB so it could be embedded for dev and smaller deployments! The process of becoming a TLP isn't that much of a concern to me. It takes time, but is worth it to establish a firm foundation for the project going forward. The main issues that concern me are the various and changing policies of the ASF. I have a hard time seeing the point of trademarks for open source projects, for example. Not sure if this is key to the current discussion but I would not mind hearing details of your concerns since we have put a bit of an effort into that area recently. The community model is another concern, I don't like the structure as much as certain alternatives in the open source world (even if I used to think it was the best approach, or at least something similar to the ASF approach). It may be possible to manage a more distributed community and code base with various fork repositories and feature/issue branches in the style of git (ie actually using git within the ASF). I suspect that the world is heading to git. I am just starting to get acquanted with it and beginning to feel like a bit of a dinosaur using SVN for our projects internally. During incubation the biggest community risk is _forcing_ a certain number of committers and PMC members. I don't want to scrape to include people in these roles as they are vital to the future of the project. I would rather let people come along, express interest, and thoroughly prove merit before they take on such a role. One of the advantages of joning an existing project is that you are not affected by the restriction on users and PMC members. As for community, regardless of the structure the various Moqui projects are now in a good place for a bigger community and it is needed for more significant growth in the projects. There are parallels to OFBiz which was mostly two people until around 2004-2005 when the project exploded (we had other contributors before then, but most not so involved or enduring). Jacopo was the first really strong contributor in 2003, and remains to this day! I'm still looking for a Jacopo for Moqui... heck, maybe it'll be Jacopo. ;) (No pressure Jacopo: I know
Re: move to git.
That's an important point indeed Pierre. One thing we need to clarify is how Git at the ASF https://git-wip-us.apache.org/ allows to search between branches and forks, compared to svn and patches in Jira Of course we could add our own policy and tools It doesn't mean I'm for using Git, it's only to allow comparing the alternatives. I have invested in using Jira and I'd really miss it... Jacques Le 21/04/2015 12:52, Pierre Smits a écrit : Sharing those improvements as patches attached to JIRA issues is a way better mechanism for exposure and review than through the distributed and competing search/find tools of today (Google et all) into all the distributed repositories or forks. Best regards, Pierre. Op dinsdag 21 april 2015 heeft Sharan Foga sharan.f...@gmail.com het volgende geschreven: Hi All I've been looking at some of what OFBiz France has done regarding addons for OFBiz . I think there are a lot of useful things that have been contributed by the community in general (not only OFBiz France) that are either sitting in forks or addons or just in Jira that haven't really been visible to the community. Making them visible gives the community more freedom and choice - whatever tool is used. Thanks Sharan On 21.4.2015 12:19, Jacques Le Roux wrote: Le 21/04/2015 12:02, David E. Jones a écrit : On 20 Apr 2015, at 23:21, Pierre Smits pierre.sm...@gmail.com wrote: Quoting: We are also prepared to be assertive regarding this situation. If the project does not move to GIT then Brainfood is willing to participate in a consortium of organizations that will peer with each other to share updates to the master branch for their local OFBiz repository. Such an arrangement will, effectively, result in a distributed master repository image. Thanks Ean for the position of *Brainfood* in this position. It comes across as 'Do it our way, or else'. You are free to make such statements and when followed through there will be consequences. For all participating in this project. One I can see standing out clearly is: no more participation in/contribution from the employees of Brainfood and from the other companies in that consortium back into the project. That's not at all what I get from Ean's comments. The magic of a community-driven project is that people can collaborate on anything they want, within the scope of the main project or as side projects. If the main project doesn't provide something desired, then it is perfectly appropriate for others to collaborate on that... better than doing it totally isolated. What Ean is talking about ties in with the general idea of distributed source management and distributed development. The general idea is that there may be many forks of the main source repo, potentially with various branches for different improvements and changes. These are generally made available publicly, like public GitHub forks of other public repositories (though with git they can be hosted anywhere). Those who make changes can request that particular changes be pulled into upstream repositories and then those who maintain the upstream repos (or the main project repo if it bubbles up that high) can review them and pull the changes if desired. Those who maintain upstream repos can also look around for useful changes in forked repos and pull them in as desired. Others who run their own forks can pull in changes from peer repositories too. It may seem like chaos to have forks and changes spread all over the place... but that isn't caused by the distributed source management approach, it's just made visible and clear by the approach. Right now this exists on a large scale for OFBiz, tons of forks and changes in them, but they are mostly not visible or publicly available so there is no way for OFBiz committers to pull changes from other repos... they basically have to be extracted into a patch file and submitted through a Jira issue. In other words, the chaos exists and the distributed source management enabled by git just makes it easier to track it all and tame it a bit. On a side note, this is one of the reasons I have concerns about making Moqui and related projects part of the ASF: the ASF community approach doesn't fit very well with this distributed source management model (pull requests are discouraged, all contributions should go through Jira issues... though I don't know that this is a strict policy). -David Interesting David, it can be compared to the OFBiz-France association effort to leverage the Nereides addons and addons manager. I let aside the licenses issues, as long as it's no part of a released package there are no problems. What do you think OFBiz-France members? Jacques If that is going to happen, I will say: 'I thank you for all the contributions you did to the project'. And I will check in my sentiments at the door. I do hope that if you do you also resign totally from this project. I rather have the community comes to its decision based on
Re: move to git.
Hi all, First to clarify things, OFBiz-france association goal is to promote Apache OFBiz into french speaking audience by giving references (information, classifications and links) to extensions (documentations, addons, patchs or packaged solution), maybe hosting some high quality not contributable extensions. Helping extensions' owner improving their quality to convert its into OFBiz contribution if possible, or referencing them for easy sharing of classified solutions. Creating a tool integrated into Apache OFBiz too manage and share anyone devs by implementing a new extension manager (http://ofbiz.markmail.org/message/goxbqcgurpoy2yfp?q=ofbiz-fr without success for now :) ) Nereide Leverage of addon solutions, like you introduce is just an illustration of this process. Nereide as a member of the association will give as example some instance of extensions, hoping that other contribution and contributor will come (and be welcome). I think that this git solution of *creating a consortium [...]* is quite different (even if i do not understand all the ins and out of it) and might be more comparable to ofbizextra effort, to give the ability for everyone to develop and share using a dedicated tool. And because everything which is committed into Apache OFBiz project has to be validated, and development within Integrators Projects do not have the same rythm/pace, ofbizextra was created to store and share unfinished/specific/not ready quality wise devs and this has to be out of Apache OFBiz. My personal opinion is (i'm not a git user), that SVN seems quite sufficient for Apache OFBiz needs. I remind me reading that there is already a git repository of the trunk branch so, if true, it can be used by contributor too make their devs using it. I'm not relevent evaluating git usage, but i do not feel a real problem using SVN. In every case, contribution will have to be given within Jira to get into the project. Best Regards Gil On 21/04/2015 12:19, Jacques Le Roux wrote: Le 21/04/2015 12:02, David E. Jones a écrit : On 20 Apr 2015, at 23:21, Pierre Smits pierre.sm...@gmail.com wrote: Quoting: We are also prepared to be assertive regarding this situation. If the project does not move to GIT then Brainfood is willing to participate in a consortium of organizations that will peer with each other to share updates to the master branch for their local OFBiz repository. Such an arrangement will, effectively, result in a distributed master repository image. Thanks Ean for the position of *Brainfood* in this position. It comes across as 'Do it our way, or else'. You are free to make such statements and when followed through there will be consequences. For all participating in this project. One I can see standing out clearly is: no more participation in/contribution from the employees of Brainfood and from the other companies in that consortium back into the project. That's not at all what I get from Ean's comments. The magic of a community-driven project is that people can collaborate on anything they want, within the scope of the main project or as side projects. If the main project doesn't provide something desired, then it is perfectly appropriate for others to collaborate on that... better than doing it totally isolated. What Ean is talking about ties in with the general idea of distributed source management and distributed development. The general idea is that there may be many forks of the main source repo, potentially with various branches for different improvements and changes. These are generally made available publicly, like public GitHub forks of other public repositories (though with git they can be hosted anywhere). Those who make changes can request that particular changes be pulled into upstream repositories and then those who maintain the upstream repos (or the main project repo if it bubbles up that high) can review them and pull the changes if desired. Those who maintain upstream repos can also look around for useful changes in forked repos and pull them in as desired. Others who run their own forks can pull in changes from peer repositories too. It may seem like chaos to have forks and changes spread all over the place... but that isn't caused by the distributed source management approach, it's just made visible and clear by the approach. Right now this exists on a large scale for OFBiz, tons of forks and changes in them, but they are mostly not visible or publicly available so there is no way for OFBiz committers to pull changes from other repos... they basically have to be extracted into a patch file and submitted through a Jira issue. In other words, the chaos exists and the distributed source management enabled by git just makes it easier to track it all and tame it a bit. On a side note, this is one of the reasons I have concerns about making Moqui and related projects part of the ASF: the ASF community
Re: move to git.
I agree it is important to consider the current situation and the possible workflows before discussing the tools. Currently we do the following: * trunk is where all development happens * most of the commits to trunk are done following the Commit Then Review workflow; sometimes, for more complex or controversial changes, we follow the Review Then Commit workflow; sometimes we create experimental branches that are then merged into the trunk * release branches are stabilization branches: snapshots of the trunk at a given point of time, then (mostly) only backporting of bugs are done * a new release branch is approximately created every year * release branches are actively maintained for 3-4 years When we discuss version control systems (e.g. svn, git) for OFBiz, we should also consider the following questions: * is the current workflow the best for OFBiz and its ecosystem? * if we want to change the workflow, which one we would be the best? For example: Forking Workflow, Gitflow Workflow, Feature Branch Workflow etc... * is the new workflow compatible with the ASF guidelines and rules? * what is the best tool for the new workflow? e.g. git, svn Regards, Jacopo On Apr 21, 2015, at 2:11 PM, Pierre Smits pierre.sm...@gmail.com wrote: As far as I can see it, this whole discussion regarding GIT vs SVN (move to GIT), is dependent on and blocked by the perceptions of (and viewpoints on) the (in)clarity surrounding how we (as the contributing community) deal with code-changing contributions (CTR vs RTC/patches vs dumps). If we don’t deal with that first, I see blockers on the road forward every time we reiterate this GIT vs SVN discussion. Like it there were before and are now. It seems we (all) need a realignment and/or re-acceptance of our G C (of the GRC) in that area first. Best regards, Pierre Smits *ORRTIZ.COM http://www.orrtiz.com* Services Solutions for Cloud- Based Manufacturing, Professional Services and Retail Trade http://www.orrtiz.com On Tue, Apr 21, 2015 at 1:22 PM, Jacopo Cappellato jacopo.cappell...@hotwaxsystems.com wrote: On Apr 21, 2015, at 12:59 PM, Adrian Crum adrian.c...@sandglass-software.com wrote: Everyone is missing the point I am trying to make. I said, ***IF*** Jacopo said something like... As the OFBiz RM, ***IF*** Jacopo said he couldn't use Subversion to manage the OFBiz project, then the need to switch to something else would be obvious. I hope that clarifies my true meaning. Adrian Crum It was clear to me since your first message but I have replied to Jacques as I was starting to feel dragged (or, in the context of git, I should say pulled) into the mix :-) Jacopo
Re: move to git.
Hi Jacques and all, I think that sharing more than anything is a reason why git has an advantage. The distributed system means that every developer is a repository and therefore you can have endless chains of code propagation up to a committer. Just imagine a scenario like the following - A team is composed of people working on a major task - Two of the members (A and B) have their own sub-teams - There is exchange of code between the sub-teams, the major team and the project committer. Furthermore, the sub-teams need to pull updated data from the main repository of the project. So you have two integrators at the sub-team level and one integrator at the top team level plus a project committer. Sometimes, I want to pull code from the sub-team. Sometimes I want to pull code from the _other_ team. Then maybe I want to _merge_ work from both teams and run all tests. Then I want to clean the commit log with git rebase to cleanup the history into major commits to submit to the project committer. Now the project owner does not know / trust me but he knows / trusts you. And you in turn trust me so you can accept my commits. I cannot imagine how to implement the above without a distributed source code management system. Furthermore, it's important to note that ofbiz is not a closed proprietary project with a sacred repository hidden in the vault of some company. You _need_ contributions from others and you need to make it very easy and accessible. You need to have the ability for people to form teams and sub-teams to support you and your project by collaborating with each other without needing a committer. This is one of the main reasons for the massive success of the Linux Kernel where each of Linus Torvald's lieutenants is a committer for a sub-system with his/her own people they trust and work closely with. Some of this stuff is briefly shown in here http://www.git-scm.com/about/distributed I hope what I wrote is resonating with you and you're willing to give this idea a chance Taher Alkhateeb On Tue, Apr 21, 2015 at 10:23 AM, Jacques Le Roux jacques.le.r...@les7arts.com wrote: Le 21/04/2015 02:08, Ean Schuessler a écrit : - Original Message - From: Jacques Le Roux jacques.le.r...@les7arts.com Subject: Re: move to git. Like Adrian and mostly for the same reasons, I don't believe we need Git. But there is one other major reason which has already been discussed in the other common ASF MLs. As Taher exulted, it's possible to create local branches. So people are able to do a lot of work alone without exchanging before committing or submitting. It will certainly not help to have this possibility. I disagree. It is useful in many situations for OFBiz developers to create a local repository that is not globally shared. What about https://github.com/apache/ofbiz ? Some customers may even require such a situation for security or legal reasons. People can do what they want with OFBiz code on their side, sharing with the community is something else (and often harder) Jacques Remember our recent discussion on the lack or core commits reviews. With Git you end with commits bursts or big patches and it's then hard to review and too late to share ideas. So unlike Adrian, I'm even strongly against it. I will not hesitate to use a -1 if necessary! We are also prepared to be assertive regarding this situation. If the project does not move to GIT then Brainfood is willing to participate in a consortium of organizations that will peer with each other to share updates to the master branch for their local OFBiz repository. Such an arrangement will, effectively, result in a distributed master repository image. If anyone else is interested in such an arrangement please feel free to speak up and we can begin the planning process.
Re: discussion: Move to Maven was:Re: svn commit: r1674216 - in /ofbiz/trunk: framework/start/pom.xml pom.xml
Hi All A reminder that this is a public list and while I understand that there is a lot of heated discussions happening here - the use of swearwords or bad language is not acceptable. Thanks Sharan -- View this message in context: http://ofbiz.135035.n4.nabble.com/Re-svn-commit-r1674216-in-ofbiz-trunk-framework-start-pom-xml-pom-xml-tp498p4667055.html Sent from the OFBiz - Dev mailing list archive at Nabble.com.
Re: move to git.
Some have argumented in this and other threads that SVN is dead and Git is the new king, and that is why the change is warranted. Here are some insights into numbers: http://programmers.stackexchange.com/questions/136079/are-there-any-statistics-that-show-the-popularity-of-git-versus-svn . If you feel that SVN should address the GIT features, I suggest you join user@subversion.a.o. or dev@subversion.a.o and collaborate there to get it improved. Yes, SVN is an Apache project called Apache Subversion. Best regards, Pierre Smits *ORRTIZ.COM http://www.orrtiz.com* Services Solutions for Cloud- Based Manufacturing, Professional Services and Retail Trade http://www.orrtiz.com On Tue, Apr 21, 2015 at 8:21 AM, Pierre Smits pierre.sm...@gmail.com wrote: Quoting: We are also prepared to be assertive regarding this situation. If the project does not move to GIT then Brainfood is willing to participate in a consortium of organizations that will peer with each other to share updates to the master branch for their local OFBiz repository. Such an arrangement will, effectively, result in a distributed master repository image. Thanks Ean for the position of *Brainfood* in this position. It comes across as 'Do it our way, or else'. You are free to make such statements and when followed through there will be consequences. For all participating in this project. One I can see standing out clearly is: no more participation in/contribution from the employees of Brainfood and from the other companies in that consortium back into the project. If that is going to happen, I will say: 'I thank you for all the contributions you did to the project'. And I will check in my sentiments at the door. I do hope that if you do you also resign totally from this project. I rather have the community comes to its decision based on sound/valid arguments, not (veiled) threats. Best regards, Pierre Smits *ORRTIZ.COM http://www.orrtiz.com* Services Solutions for Cloud- Based Manufacturing, Professional Services and Retail Trade http://www.orrtiz.com On Tue, Apr 21, 2015 at 2:08 AM, Ean Schuessler e...@brainfood.com wrote: - Original Message - From: Jacques Le Roux jacques.le.r...@les7arts.com Subject: Re: move to git. Like Adrian and mostly for the same reasons, I don't believe we need Git. But there is one other major reason which has already been discussed in the other common ASF MLs. As Taher exulted, it's possible to create local branches. So people are able to do a lot of work alone without exchanging before committing or submitting. It will certainly not help to have this possibility. I disagree. It is useful in many situations for OFBiz developers to create a local repository that is not globally shared. Some customers may even require such a situation for security or legal reasons. Remember our recent discussion on the lack or core commits reviews. With Git you end with commits bursts or big patches and it's then hard to review and too late to share ideas. So unlike Adrian, I'm even strongly against it. I will not hesitate to use a -1 if necessary! We are also prepared to be assertive regarding this situation. If the project does not move to GIT then Brainfood is willing to participate in a consortium of organizations that will peer with each other to share updates to the master branch for their local OFBiz repository. Such an arrangement will, effectively, result in a distributed master repository image. If anyone else is interested in such an arrangement please feel free to speak up and we can begin the planning process.
Re: move to git.
Taher, Nothing in your reply is new or different. People have been doing that for years with Subversion. Git did not invent local repositories. Connecting a local Git repository to the OFBiz Subversion repository is a problem for some, that is why we are having this discussion. So far, two proposals have been made: 1. Switch the OFBiz project to Git. 2. Host a separate Git repo that is a copy of the OFBiz Subversion repo. How those proposals affect OFBiz developers: 1. Subversion users must switch to Git clients and learn Git. 2. Git users can access the project through the Git repo, Subversion users continue using Subversion with the main OFBiz repo. Switching the main repo to Git does not add anything to the project itself. As I said before, Subversion handles our simple needs just fine. If Jacopo said something like, Managing our releases is impossible with Subversion, we really need to switch to Git - then we wouldn't be having this discussion, it would just happen because the need for the switch is obvious. But Jacopo is not saying that, and we don't have a problem using Subversion to manage the project. Adrian Crum Sandglass Software www.sandglass-software.com On 4/21/2015 9:19 AM, Taher Alkhateeb wrote: Hi Jacques and all, I think that sharing more than anything is a reason why git has an advantage. The distributed system means that every developer is a repository and therefore you can have endless chains of code propagation up to a committer. Just imagine a scenario like the following - A team is composed of people working on a major task - Two of the members (A and B) have their own sub-teams - There is exchange of code between the sub-teams, the major team and the project committer. Furthermore, the sub-teams need to pull updated data from the main repository of the project. So you have two integrators at the sub-team level and one integrator at the top team level plus a project committer. Sometimes, I want to pull code from the sub-team. Sometimes I want to pull code from the _other_ team. Then maybe I want to _merge_ work from both teams and run all tests. Then I want to clean the commit log with git rebase to cleanup the history into major commits to submit to the project committer. Now the project owner does not know / trust me but he knows / trusts you. And you in turn trust me so you can accept my commits. I cannot imagine how to implement the above without a distributed source code management system. Furthermore, it's important to note that ofbiz is not a closed proprietary project with a sacred repository hidden in the vault of some company. You _need_ contributions from others and you need to make it very easy and accessible. You need to have the ability for people to form teams and sub-teams to support you and your project by collaborating with each other without needing a committer. This is one of the main reasons for the massive success of the Linux Kernel where each of Linus Torvald's lieutenants is a committer for a sub-system with his/her own people they trust and work closely with. Some of this stuff is briefly shown in here http://www.git-scm.com/about/distributed I hope what I wrote is resonating with you and you're willing to give this idea a chance Taher Alkhateeb On Tue, Apr 21, 2015 at 10:23 AM, Jacques Le Roux jacques.le.r...@les7arts.com wrote: Le 21/04/2015 02:08, Ean Schuessler a écrit : - Original Message - From: Jacques Le Roux jacques.le.r...@les7arts.com Subject: Re: move to git. Like Adrian and mostly for the same reasons, I don't believe we need Git. But there is one other major reason which has already been discussed in the other common ASF MLs. As Taher exulted, it's possible to create local branches. So people are able to do a lot of work alone without exchanging before committing or submitting. It will certainly not help to have this possibility. I disagree. It is useful in many situations for OFBiz developers to create a local repository that is not globally shared. What about https://github.com/apache/ofbiz ? Some customers may even require such a situation for security or legal reasons. People can do what they want with OFBiz code on their side, sharing with the community is something else (and often harder) Jacques Remember our recent discussion on the lack or core commits reviews. With Git you end with commits bursts or big patches and it's then hard to review and too late to share ideas. So unlike Adrian, I'm even strongly against it. I will not hesitate to use a -1 if necessary! We are also prepared to be assertive regarding this situation. If the project does not move to GIT then Brainfood is willing to participate in a consortium of organizations that will peer with each other to share updates to the master branch for their local OFBiz repository. Such an arrangement will, effectively, result in a distributed master repository image. If anyone else is interested in such an
Fwd: [jira] [Apache Infrastructure] Remove spam user in Jira
Done Jacques Message transféré Sujet : [jira] [Apache Infrastructure] Remove spam user in Jira Date : Tue, 21 Apr 2015 09:01:58 + (UTC) De :Gavin j...@apache.org Pour : jacques.le.r...@les7arts.com Request Remove spam user in Jira with key INFRA-9489 has been resolved... *Apache Infrastructure* - Something else... https://issues.apache.org/jira/servicedesk/customer/portal/1 Reference: *INFRA-9489* https://issues.apache.org/jira/servicedesk/customer/portal/1/INFRA-9489 Remove spam user in Jira https://issues.apache.org/jira/servicedesk/customer/portal/1/INFRA-9489 Closed Gavin Today 11:01 comments and user deleted. Status changed to *Closed* with resolution *Fixed* Today 11:01 You can view the full request https://issues.apache.org/jira/servicedesk/customer/portal/1/INFRA-9489 Previous activity Jacques Le Roux Today 08:30 This is not the 1st time we have this spammer there. Unfortunately I guess there are no means to prevent that, not a big deal anyway Details Description Please remove the spam user https://issues.apache.org/jira/secure/ViewProfile.jspa?name=sourabhgupta Thanks This message is automatically generated by JIRA Service Desk. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA Service Desk, see: http://www.atlassian.com/software/jira/service-desk
Re: move to git.
That wasn't what happened to me. Here are the steps I took and the outcome:
1. Git pull to update my local copy.
2. Make changes to 4 files.
3. Stash push.
4. Pull to get latest repo changes.
5. Stash pop.
6. Commit - 4 files changed.
7. Push - dozens of files changed.
!!!???
8. Check commit log - 4 files changed.
Why did my push change dozens of files I didn't touch? Basically,
several days of other people's work were reverted by my push.
My local copy says I changed only 4 files, but a diff of the repo before
and after my push shows that many more files were changed. Even the Git
gurus couldn't figure that out. Meanwhile, the unintended changes had to
be fixed by hand.
Adrian Crum
Sandglass Software
www.sandglass-software.com
On 4/21/2015 1:12 AM, Adam Heath wrote:
I used to be in the same boat; in the early days, I would blame git for
losing my work. Damn you frigging piece of software!
However, I also realized that the linux-kernel was using it to do much
more complex things than I was, so I toiled on. It took me a long time,
but I was finally able to figure out how to make use of git's features.
The main thing that keeps you from losing work, is to commit
*everything* to git. If you leave *anything* in your $working_tree, not
committed, then yes, sometimes things get confused. But once you have
everything committed to git, there are certain things that git helps you
with, with regard to keeping copies of stuff around.
==
# git config --global rerere.enabled true
# (echo adfadsfasdf; date) new-file
# git branch before-new-file
# git add new-file
# git commit -m This is my cool new file, yipee!
# git log
# git checkout before-new-file
# git branch -f master before-new-file
# git checkout master
# ls new-file # hmm, where did it go?
# git reflog # hmm, seems to show the commit from above
# git log trunk # commit is gone
# git log trunk@{1} # this shows the commit, and the file
==
This is just one of the powerful features that git has. I have rerere
enabled locally, but don't use it often. I enabled it long ago, because
I saw that it keeps copies of all my rebasing and branching, so that I
can feel safer about having this safety net.
Also, I when back in time, and found an older copy of the previous ofbiz
svn tree, and underlayed it into the current git-svn checkout, so I
have git history going all the way back to 2003.
On 04/20/2015 02:53 AM, Adrian Crum wrote:
I don't agree that all major contributors are using git.
Personally, I find Git to be an overly complicated solution to a
simple problem. It frequently does bizarre things that no one
understands, and you are left with things being mysteriously reverted
for unknown reasons.
This isn't a -1 vote though. I'm just making it clear that I will be
dragged kicking and screaming into using it.
Adrian Crum
Sandglass Software
www.sandglass-software.com
On 4/20/2015 5:38 AM, Hans Bakker wrote:
As discussed at apachecon in Austin, i propose to switch from svn to git
for the ofbiz repository. The main reason being that all major
contributors are using git and contributions are cumbersome, further,
git allows for better branching and merging.
Regards,
Hans
[jira] [Commented] (OFBIZ-6268) Improve Start.java Component Loading
[ https://issues.apache.org/jira/browse/OFBIZ-6268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14504697#comment-14504697 ] Jacopo Cappellato commented on OFBIZ-6268: -- I am not aware of any code dependencies (there are a few in the loader configurations in start.properties) but that is a config file. Just out of curiosity, did you measure how much this change will improve performance at startup? (in terms of milliseconds) Improve Start.java Component Loading Key: OFBIZ-6268 URL: https://issues.apache.org/jira/browse/OFBIZ-6268 Project: OFBiz Issue Type: Improvement Components: framework Affects Versions: Upcoming Branch Reporter: Adrian Crum Priority: Minor Attachments: OFBIZ-6268.patch The current code for loading components parses configuration files twice. This issue is intended for review of code improvements. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (OFBIZ-5441) URLs in PDF files are not handled correctly
[
https://issues.apache.org/jira/browse/OFBIZ-5441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14501620#comment-14501620
]
Jacques Le Roux edited comment on OFBIZ-5441 at 4/21/15 8:26 AM:
-
I checked, this is no longer a problem using NoTo fonts, see OFBIZ-5917
was (Author: jacques.le.roux):
I checked, this is no longer a problem using NoTo fonts, see r1674586
URLs in PDF files are not handled correctly
---
Key: OFBIZ-5441
URL: https://issues.apache.org/jira/browse/OFBIZ-5441
Project: OFBiz
Issue Type: Bug
Components: accounting
Affects Versions: Trunk
Reporter: Jacques Le Roux
Priority: Minor
When a PDF file contains a reference to a promotion like when you buy a
WG-5569 (Tiny Chrome Widget) and get a free WG- (Micro Chrome Widget).
You end with a corresponding invoice containing Spend more than $100 on
your favorite widgets and gizmos and get a free a
href=/ecommerce/control/product?category_id=20111amp;product_id=WG-Micro
Chrome Widget/a! instead of a real link.
It's possible to generare a link in a PDF with FOP, we need to
# dynamically define a fop.base using a ftl transform refs:
http://xmlgraphics.apache.org/fop/0.95/configuration.html#general-elements
http://xmlgraphics.apache.org/fop/faq.html#MalformedURL
# here is an example from ProductionRun.fo.ftl
{code}
fo:table-cell padding=2pt
fo:blockfo:basic-link background-color=lightblue
external-destination=@ofbizContentUrl/content/control/ViewBinaryDataResource?dataResourceId=${productionRunContent.drDataResourceId}/@ofbizContentUrl${uiLabelMap.CommonView}/fo:basic-link/fo:block
/fo:table-cell
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OFBIZ-6270) base/json/JSON has been removed, with no deprecation window
[ https://issues.apache.org/jira/browse/OFBIZ-6270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14504656#comment-14504656 ] Adrian Crum commented on OFBIZ-6270: I agree that deprecating things before they are removed is a best practice. At the same time, this particular change was easy to fix in our client code. In most cases it only took a SR to change package names, and in others the difference was obvious and easy to fix. base/json/JSON has been removed, with no deprecation window --- Key: OFBIZ-6270 URL: https://issues.apache.org/jira/browse/OFBIZ-6270 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: Trunk, 12.04.04 Reporter: Adam Heath Assignee: Adam Heath Priority: Critical The antlr-based json parser(at org.ofbiz.base.json.JSON.cc) was removed last October(2014-10-27). However, no backwards-compatible class was left in place, with a proper @Deprecation tag applied. The proper approach should have been to leave the class in place, adding @Deprecation, and leaving the json-lib.jar in place. Then, after one successful release, removing the actual code. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-6268) Improve Start.java Component Loading
[ https://issues.apache.org/jira/browse/OFBIZ-6268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14504708#comment-14504708 ] Jacopo Cappellato commented on OFBIZ-6268: -- The fact that this patch didn't change the class loader tree is a good thing! Thanks. Improve Start.java Component Loading Key: OFBIZ-6268 URL: https://issues.apache.org/jira/browse/OFBIZ-6268 Project: OFBiz Issue Type: Improvement Components: framework Affects Versions: Upcoming Branch Reporter: Adrian Crum Priority: Minor Attachments: OFBIZ-6268.patch The current code for loading components parses configuration files twice. This issue is intended for review of code improvements. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: Discussion: Replace framework by Moqui.
Le 20/04/2015 22:27, Pierre Smits a écrit : @Nicolas: in the end it is code change. Does your point of view reflect a veto? If the code change and the backward compatibility is present, no worries. We are an enterprise automation software not just a framework. Many companies trust in this stability and it's the main reason that I love OFBiz. I think we are relatively smart to don't break it ;) If I don't need backward compatibility without making customer project directly with Moqui/mantle, why keep Apache OFBiz ? Best regards, Pierre Smits *ORRTIZ.COM http://www.orrtiz.com* Services Solutions for Cloud- Based Manufacturing, Professional Services and Retail Trade http://www.orrtiz.com On Mon, Apr 20, 2015 at 10:23 PM, Nicolas Malin nicolas.ma...@nereide.fr wrote: We have to be aware that every project (proprietary or Open Source) somewhere in the lifespan faces the moment of breaking backwards compatibility of their products. Even today there are still some products whose owners had to walk that walk and survived But that is more about the trustworthiness of the owner/project. And even then it were hard walks Moqui is very attractive, at this time I think it will be embed in OFBiz framework and not replace it. Because it's important to have the backward compatibility (java interface, and xml model reader can be used to make sure it). It's the OFBiz strong ! My point of view is : no backward compatibility, no discussion :) Nicolas Best regards, Pierre Smits *ORRTIZ.COM http://www.orrtiz.com* Services Solutions for Cloud- Based Manufacturing, Professional Services and Retail Trade http://www.orrtiz.com On Mon, Apr 20, 2015 at 8:39 PM, David E. Jones d...@me.com wrote: On 19 Apr 2015, at 22:31, Hans Bakker mailingl...@antwebsystems.com wrote: Again, as discussed at the ApacheCon in Austin we should start setting up a plan how to best move the ERP application to the Moqui framework. Moqui should not be part of the Apache foundation however the ERP application should remain there. Not only will it improve development of the ERP system but also will establish a clean separation between application and frameworks and hopefully getting David Jones back into the project. Yes, I realize i open the pandora box :-) but we need to make some major decisions I'll write this general reply with my OFBiz hat on, not my Moqui one. For Moqui Framework being used by OFBiz would be fantastic. It would bring a lot of well needed use and attention to the project and get it to a level that would take much longer with the current pace of growth. The growth is increasing, but it's nothing like the early years of OFBiz when the marketplace was so different... at that time OFBiz was unique as there weren't many feature-rich open source ecommerce or ERP systems, especially not in Java! I still find it amazing that OFBiz took off as much as it did... I was 23 years old when I started it, and only had 2 years of full-time development work behind me, and only 1 year of that was on ecommerce and ERP systems. Andrew had more experience with custom ecommerce development, but mostly in Perl IIRC. Anyway, enough nostalgia, back to the present. Using Moqui Framework in OFBiz would involve some really significant changes. The Moqui API is much cleaner (and everything is available through the single ExecutionContext class), but much different from the scattered static classes of the OFBiz framework. It may be possible to refactor much of the code with some regex search/replace wizardry, but there is a LOT of code in OFBiz to change. The data model and to some extent service definitions would be easy. I have some FTL templates for transforming those that I'd be happy to share (they are in a private repo right now). I used these to create the little Moqui component that has the OFBiz data model from version 10.04 which I used with a client to run a sort of OFBiz/Moqui hybrid. On that note... if anyone wants to experiment with this that might be a good place to start: get the latest data model definitions in a Moqui component, deploy the Moqui WAR in the same servlet container as OFBiz (just drop it in an OFBiz component) and then run them in parallel accessing the same DB and play with migrating a few screens/etc. IMO the biggest questions/concerns should be: 1. the significant effort required to do the migration 2. the impact on current users and applications OFBiz would end up as a very different beast after such changes, there is no way around it. For example screen hierarchies, nesting, and URLs are handled totally different in Moqui. There are some very cool newer open source tools used in Moqui, and some cool features in Moqui that don't (yet) exist in OFBiz, and many of the more advanced and recent ones aren't mentioned here, but this is a basic list of fundamental differences between the two frameworks (see the OFBiz: How does it compare to Moqui? section near the
[jira] [Closed] (OFBIZ-4837) Separator Error in data file tools
[ https://issues.apache.org/jira/browse/OFBIZ-4837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacques Le Roux closed OFBIZ-4837. -- Closing Separator Error in data file tools -- Key: OFBIZ-4837 URL: https://issues.apache.org/jira/browse/OFBIZ-4837 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: Trunk Reporter: Gil Portenseigne Assignee: Deepak Dixit Priority: Minor Labels: data, parsing Fix For: 14.12.01, 12.04.06, 13.07.02, Upcoming Branch Attachments: OFBIZ-4837.patch, OFBIZ-4837.patch, OFBIZ-4837_2.patch, dataDefinition.xml, dataSample.csv, result.xml, resultBefore.xml Original Estimate: 0.5h Remaining Estimate: 0.5h In https://demo-trunk.ofbiz.apache.org/webtools/control/viewdatafile There is a bug when defining simple separator (for instance ,) in definition file, and when in data file a string data contains the separator. This one sould not be interpreted in data parsing. To illustrate a bit more, i add small sample files to reproduce the problem. And the patch which fix the bug. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-6267) Replace ProductionRun.fo with widgets
[ https://issues.apache.org/jira/browse/OFBIZ-6267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14504629#comment-14504629 ] Jacques Le Roux commented on OFBIZ-6267: Wait cant's this part be extracted (I guess not, but asking...)? Replace ProductionRun.fo with widgets - Key: OFBIZ-6267 URL: https://issues.apache.org/jira/browse/OFBIZ-6267 Project: OFBiz Issue Type: Improvement Components: manufacturing Reporter: Christian Carlow Assignee: Nicolas Malin -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-6268) Improve Start.java Component Loading
[
https://issues.apache.org/jira/browse/OFBIZ-6268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14504682#comment-14504682
]
Jacopo Cappellato commented on OFBIZ-6268:
--
Thank you Adrian.
What I don't like about this new approach is that it adds to the
framework/start module a dependency on the inner layout of the base
component:
{code}
classPath.addComponent(ofbizHomeTmp.concat(framework/base/config));
classPath.addComponent(ofbizHomeTmp.concat(framework/base/dtd));
classPath.addFilesFromPath(new
File(ofbizHomeTmp.concat(framework/base/lib)));
classPath.addFilesFromPath(new
File(ofbizHomeTmp.concat(framework/base/lib/commons)));
classPath.addComponent(ofbizHomeTmp.concat(framework/base/build/lib/ofbiz-base.jar));
{code}
while with the current code the dependency is just on the layout of the OFBiz
folder:
{code}
collectClasspathEntries(new File(home, framework), classPath,
libraryPath);
collectClasspathEntries(new File(home, applications), classPath,
libraryPath);
collectClasspathEntries(new File(home, specialpurpose), classPath,
libraryPath);
collectClasspathEntries(new File(home, hot-deploy), classPath,
libraryPath);
{code}
Moreover, does the new code introduce any changes to the ClassLoader tree?
(i.e. a new ClassLoader in the parent-child path)
I am asking because it is difficult for me to figure out by reviewing the patch.
If it adds new levels, even if this is not a big deal, then we should decide if
it is worth to improve startup performance and penalize runtime performance
(both by tiny fractions).
Improve Start.java Component Loading
Key: OFBIZ-6268
URL: https://issues.apache.org/jira/browse/OFBIZ-6268
Project: OFBiz
Issue Type: Improvement
Components: framework
Affects Versions: Upcoming Branch
Reporter: Adrian Crum
Priority: Minor
Attachments: OFBIZ-6268.patch
The current code for loading components parses configuration files twice.
This issue is intended for review of code improvements.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OFBIZ-6267) Replace ProductionRun.fo with widgets
[ https://issues.apache.org/jira/browse/OFBIZ-6267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14504683#comment-14504683 ] Jacques Le Roux commented on OFBIZ-6267: Pierre, I try to not put too much pressure on contributors, I know it takes already some efforts to contribute. So I was just asking :) Replace ProductionRun.fo with widgets - Key: OFBIZ-6267 URL: https://issues.apache.org/jira/browse/OFBIZ-6267 Project: OFBiz Issue Type: Improvement Components: manufacturing Reporter: Christian Carlow Assignee: Nicolas Malin -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: Discussion: Replace framework by Moqui.
Fascinating diagram in that link from The Economist. I had no idea IBM had such huge market share in the past! It's good to see the industry becoming more distributed, ie market share spread across a larger number of companies. Thanks, nice to be engaged in the project here and there. No, I wasn't at ApacheCon last week, a bit outside my current budgets (both time and money), especially with competing priorities like visiting family and friends... which I'm sure is the case for many would have liked to attend. -David On 21 Apr 2015, at 01:12, Pierre Smits pierre.sm...@gmail.com wrote: Nice to have you back and engaged, David. My apologies if I didn't express that earlier. Were you at ACNA15 also? Best regards, Pierre Smits *ORRTIZ.COM http://www.orrtiz.com* Services Solutions for Cloud- Based Manufacturing, Professional Services and Retail Trade http://www.orrtiz.com On Tue, Apr 21, 2015 at 8:59 AM, Pierre Smits pierre.sm...@gmail.com wrote: Quoting: I suspect that the world is heading to git. I am just starting to get acquanted with it and beginning to feel like a bit of a dinosaur using SVN for our projects internally. That should be in another thread. Nevertheless, such can be said regarding a lot of (also unrelated) subjects/things which are still happily used by a great number. See the 'dinosaur' in this: http://cdn.static-economist.com/sites/default/files/imagecache/original-size/images/print-edition/20150404_WBC737_0.png Best regards, Pierre Smits *ORRTIZ.COM http://www.orrtiz.com* Services Solutions for Cloud- Based Manufacturing, Professional Services and Retail Trade http://www.orrtiz.com On Tue, Apr 21, 2015 at 3:43 AM, Ron Wheeler rwhee...@artifact-software.com wrote: On 20/04/2015 5:07 PM, David E. Jones wrote: On 20 Apr 2015, at 12:48, Ron Wheeler rwhee...@artifact-software.com wrote: On 20/04/2015 3:11 PM, David E. Jones wrote: On 20 Apr 2015, at 11:35, Ron Wheeler rwhee...@artifact-software.com wrote: Would Moqui become a sub-project of OFBiz with distinct deliverable with an Apache license? Or is that too much community? IMO they are better as distinct projects. There is a chance Moqui Framework could become a separate ASF project, though the name Apache Moqui is oddly contradictory (I chose the name based on Moqui Marbles, but it is also another name for the Hopi tribe). More seriously, these days I like the distributed and moderated approaches used in the Linux kernel more than the community approach mandated by the ASF. What would be the problem of it being part of OFBiz in the same way that FOP and Batik are part of the XLMGraphics project or Jetspeed is part of the Portals project. A lot less work than a TLP but still benefiting from Apache. Would not have to call of Apache Moqui. It would just be Moqui , part of Apache OfBiz XML Graphics and Portals are both umbrella projects, meant to have sub-projects, and OFBiz is not. OFBiz could be restructured that way, and perhaps even have sub-projects without that restructuring sort of like the Jackrabbit Oak project, but still not sure if it makes sense. On that note: if a Moqui-based (or Moqui and Mantle based) version of OFBiz were built it might make sense as a sub-project just like Oak is of Jackrabbit. On a far side note: Oak looks great but I wish it ran on something other than MongoDB so it could be embedded for dev and smaller deployments! The process of becoming a TLP isn't that much of a concern to me. It takes time, but is worth it to establish a firm foundation for the project going forward. The main issues that concern me are the various and changing policies of the ASF. I have a hard time seeing the point of trademarks for open source projects, for example. Not sure if this is key to the current discussion but I would not mind hearing details of your concerns since we have put a bit of an effort into that area recently. The community model is another concern, I don't like the structure as much as certain alternatives in the open source world (even if I used to think it was the best approach, or at least something similar to the ASF approach). It may be possible to manage a more distributed community and code base with various fork repositories and feature/issue branches in the style of git (ie actually using git within the ASF). I suspect that the world is heading to git. I am just starting to get acquanted with it and beginning to feel like a bit of a dinosaur using SVN for our projects internally. During incubation the biggest community risk is _forcing_ a certain number of committers and PMC members. I don't want to scrape to include people in these roles as they are vital to the future of the project. I would rather let people come along, express interest, and thoroughly prove merit before they take on such a role. One of the advantages of joning an existing
Re: move to git.
Le 21/04/2015 02:14, Adam Heath a écrit :
On 04/20/2015 07:12 PM, Adam Heath wrote:
I used to be in the same boat; in the early days, I would blame git for losing my work.
Damn you frigging piece of software!
However, I also realized that the linux-kernel was using it to do much more complex things than I was, so I toiled on. It took me a long time, but
I was finally able to figure out how to make use of git's features.
Dare I point the linux-kernel and OFBiz are somehow different? We have 18
active committers, I guess linux-kernel has (much?) more...
I read it's even organised in a hierarchy
http://stackoverflow.com/questions/4166530/how-to-manage-a-hierarchy-of-committers-like-linux-kernel-dev
I believe Git was created because Linus needed to delegate but still have the
control... Why do we need to switch form Svn to Git is my question?
I prefer to focus on other fields in OFBiz like
OFBiz : open or in progress
https://issues.apache.org/jira/issues/?filter=12311912#
Patch Available in OFBiz
https://issues.apache.org/jira/issues/?filter=12314132
The main thing that keeps you from losing work, is to commit *everything* to git. If you leave *anything* in your $working_tree, not committed,
then yes, sometimes things get confused. But once you have everything committed to git, there are certain things that git helps you with, with
regard to keeping copies of stuff around.
==
# git config --global rerere.enabled true
# (echo adfadsfasdf; date) new-file
# git branch before-new-file
# git add new-file
# git commit -m This is my cool new file, yipee!
# git log
# git checkout before-new-file
# git branch -f master before-new-file
# git checkout master
# ls new-file # hmm, where did it go?
# git reflog # hmm, seems to show the commit from above
# git log trunk # commit is gone
# git log trunk@{1} # this shows the commit, and the file
==
Gah, too many git features. git rerere is a feature to cache rebase
resolutions; the feature being discussed here is not the same thing.
Well, so I need to dive deep in Git, but what for? Do I really miss that as an
OFBiz committer? I hope you see my preferences...
Jacques
This is just one of the powerful features that git has. I have rerere enabled locally, but don't use it often. I enabled it long ago, because I
saw that it keeps copies of all my rebasing and branching, so that I can feel safer about having this safety net.
Also, I when back in time, and found an older copy of the previous ofbiz svn tree, and underlayed it into the current git-svn checkout, so I have
git history going all the way back to 2003.
On 04/20/2015 02:53 AM, Adrian Crum wrote:
I don't agree that all major contributors are using git.
Personally, I find Git to be an overly complicated solution to a simple problem. It frequently does bizarre things that no one understands, and
you are left with things being mysteriously reverted for unknown reasons.
This isn't a -1 vote though. I'm just making it clear that I will be dragged
kicking and screaming into using it.
Adrian Crum
Sandglass Software
www.sandglass-software.com
On 4/20/2015 5:38 AM, Hans Bakker wrote:
As discussed at apachecon in Austin, i propose to switch from svn to git
for the ofbiz repository. The main reason being that all major
contributors are using git and contributions are cumbersome, further,
git allows for better branching and merging.
Regards,
Hans
[jira] [Comment Edited] (OFBIZ-6267) Replace ProductionRun.fo with widgets
[ https://issues.apache.org/jira/browse/OFBIZ-6267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14504629#comment-14504629 ] Jacques Le Roux edited comment on OFBIZ-6267 at 4/21/15 8:51 AM: - Wait can't this part be extracted (I guess not, but asking...)? was (Author: jacques.le.roux): Wait cant's this part be extracted (I guess not, but asking...)? Replace ProductionRun.fo with widgets - Key: OFBIZ-6267 URL: https://issues.apache.org/jira/browse/OFBIZ-6267 Project: OFBiz Issue Type: Improvement Components: manufacturing Reporter: Christian Carlow Assignee: Nicolas Malin -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (OFBIZ-6268) Improve Start.java Component Loading
[ https://issues.apache.org/jira/browse/OFBIZ-6268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14504697#comment-14504697 ] Jacopo Cappellato edited comment on OFBIZ-6268 at 4/21/15 9:49 AM: --- I am not aware of any code dependencies; there are a few in the loader configurations in start.properties, but that is a config file. Just out of curiosity, did you measure how much this change will improve performance at startup? (in terms of milliseconds) was (Author: jacopoc): I am not aware of any code dependencies (there are a few in the loader configurations in start.properties) but that is a config file. Just out of curiosity, did you measure how much this change will improve performance at startup? (in terms of milliseconds) Improve Start.java Component Loading Key: OFBIZ-6268 URL: https://issues.apache.org/jira/browse/OFBIZ-6268 Project: OFBiz Issue Type: Improvement Components: framework Affects Versions: Upcoming Branch Reporter: Adrian Crum Priority: Minor Attachments: OFBIZ-6268.patch The current code for loading components parses configuration files twice. This issue is intended for review of code improvements. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-6268) Improve Start.java Component Loading
[ https://issues.apache.org/jira/browse/OFBIZ-6268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14504710#comment-14504710 ] Adrian Crum commented on OFBIZ-6268: Let's back up for a second. I understand the changes you made and why you made them. The problem is with your implementation - you caused the same files to be parsed twice. I am merely removing the double parsing, your other changes (and your intent) are intact. It would help if you applied the patch and actually looked at the code. Improve Start.java Component Loading Key: OFBIZ-6268 URL: https://issues.apache.org/jira/browse/OFBIZ-6268 Project: OFBiz Issue Type: Improvement Components: framework Affects Versions: Upcoming Branch Reporter: Adrian Crum Priority: Minor Attachments: OFBIZ-6268.patch The current code for loading components parses configuration files twice. This issue is intended for review of code improvements. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: Discussion: Replace framework by Moqui.
Quoting: I suspect that the world is heading to git. I am just starting to get acquanted with it and beginning to feel like a bit of a dinosaur using SVN for our projects internally. That should be in another thread. Nevertheless, such can be said regarding a lot of (also unrelated) subjects/things which are still happily used by a great number. See the 'dinosaur' in this: http://cdn.static-economist.com/sites/default/files/imagecache/original-size/images/print-edition/20150404_WBC737_0.png Best regards, Pierre Smits *ORRTIZ.COM http://www.orrtiz.com* Services Solutions for Cloud- Based Manufacturing, Professional Services and Retail Trade http://www.orrtiz.com On Tue, Apr 21, 2015 at 3:43 AM, Ron Wheeler rwhee...@artifact-software.com wrote: On 20/04/2015 5:07 PM, David E. Jones wrote: On 20 Apr 2015, at 12:48, Ron Wheeler rwhee...@artifact-software.com wrote: On 20/04/2015 3:11 PM, David E. Jones wrote: On 20 Apr 2015, at 11:35, Ron Wheeler rwhee...@artifact-software.com wrote: Would Moqui become a sub-project of OFBiz with distinct deliverable with an Apache license? Or is that too much community? IMO they are better as distinct projects. There is a chance Moqui Framework could become a separate ASF project, though the name Apache Moqui is oddly contradictory (I chose the name based on Moqui Marbles, but it is also another name for the Hopi tribe). More seriously, these days I like the distributed and moderated approaches used in the Linux kernel more than the community approach mandated by the ASF. What would be the problem of it being part of OFBiz in the same way that FOP and Batik are part of the XLMGraphics project or Jetspeed is part of the Portals project. A lot less work than a TLP but still benefiting from Apache. Would not have to call of Apache Moqui. It would just be Moqui , part of Apache OfBiz XML Graphics and Portals are both umbrella projects, meant to have sub-projects, and OFBiz is not. OFBiz could be restructured that way, and perhaps even have sub-projects without that restructuring sort of like the Jackrabbit Oak project, but still not sure if it makes sense. On that note: if a Moqui-based (or Moqui and Mantle based) version of OFBiz were built it might make sense as a sub-project just like Oak is of Jackrabbit. On a far side note: Oak looks great but I wish it ran on something other than MongoDB so it could be embedded for dev and smaller deployments! The process of becoming a TLP isn't that much of a concern to me. It takes time, but is worth it to establish a firm foundation for the project going forward. The main issues that concern me are the various and changing policies of the ASF. I have a hard time seeing the point of trademarks for open source projects, for example. Not sure if this is key to the current discussion but I would not mind hearing details of your concerns since we have put a bit of an effort into that area recently. The community model is another concern, I don't like the structure as much as certain alternatives in the open source world (even if I used to think it was the best approach, or at least something similar to the ASF approach). It may be possible to manage a more distributed community and code base with various fork repositories and feature/issue branches in the style of git (ie actually using git within the ASF). I suspect that the world is heading to git. I am just starting to get acquanted with it and beginning to feel like a bit of a dinosaur using SVN for our projects internally. During incubation the biggest community risk is _forcing_ a certain number of committers and PMC members. I don't want to scrape to include people in these roles as they are vital to the future of the project. I would rather let people come along, express interest, and thoroughly prove merit before they take on such a role. One of the advantages of joning an existing project is that you are not affected by the restriction on users and PMC members. As for community, regardless of the structure the various Moqui projects are now in a good place for a bigger community and it is needed for more significant growth in the projects. There are parallels to OFBiz which was mostly two people until around 2004-2005 when the project exploded (we had other contributors before then, but most not so involved or enduring). Jacopo was the first really strong contributor in 2003, and remains to this day! I'm still looking for a Jacopo for Moqui... heck, maybe it'll be Jacopo. ;) (No pressure Jacopo: I know you're a busy man and doing fantastic and important work elsewhere including OFBiz, Hotwax, and other projects you contribute to.) As for licensing: the public domain license is even less restrictive than the Apache 2 license. The one thing that bothers me about the licensing approach, that I'll freely admit but that I'm not sure how to handle better, is the explicit patent grant that is
Re: [jira] [Commented] (OFBIZ-5522) Introduce websocket usage
Thanks jacques, I 'd gone the same :) Le 21/04/2015 08:31, Jacques Le Roux a écrit : FYI: I have sent a request to remove the spammer user at https://issues.apache.org/jira/servicedesk/customer/portal/1/create/3 Jacques Le 21/04/2015 05:46, sourabh gupta (JIRA) a écrit : [ https://issues.apache.org/jira/browse/OFBIZ-5522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14504248#comment-14504248 ] sourabh gupta commented on OFBIZ-5522: -- http://6packersandmovers.in/packers-and-movers-ahmedabad/ http://6packersandmovers.in/packers-and-movers-surat/ http://6packersandmovers.in/packers-and-movers-rajkot/ http://6packersandmovers.in/packers-and-movers-vadodara/ Introduce websocket usage - Key: OFBIZ-5522 URL: https://issues.apache.org/jira/browse/OFBIZ-5522 Project: OFBiz Issue Type: Task Components: framework Affects Versions: Trunk Reporter: Jacques Le Roux Priority: Minor After a discussion with Ean, was suggested (draft here): You need a service that lets you subscribe a widget to an entity and then propagate change events to the widget as the entity is modified. A generic mechanism like that could eventually expand to be a general purpose data bound widgets system that mostly looks like the existing system but magically reflects updates. Could be used with/for * The entity cache and webforms to automatically update views when data changes. * Replaces the current system notes * Create a dashboard type pages (to be discussed futher) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Tracks proposal 4 Apachecon ACEU15
Hi all, Now that ACNA15 has passed I have initiated the thread regarding potential tracks/interest areas in the mailing list of apachecon-discuss@a.o. and comdev@a.o. See here for the archives of it: http://apachecon.markmail.org/message/7ezkr5dubt6ota4c and here http://community.markmail.org/message/x3fqjztpiwe6npzj As of now, I don't see where our kites are going to fly. We just have to wait it out and keep tabs... Nevertheless, I thank you for your time and interest. Best regards, Pierre Smits *ORRTIZ.COM http://www.orrtiz.com* Services Solutions for Cloud- Based Manufacturing, Professional Services and Retail Trade http://www.orrtiz.com
[jira] [Commented] (OFBIZ-6270) base/json/JSON has been removed, with no deprecation window
[ https://issues.apache.org/jira/browse/OFBIZ-6270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14504651#comment-14504651 ] Jacopo Cappellato commented on OFBIZ-6270: -- The proper approach you mention is definitely a good way to go but it is not something that we are enforcing and/or implementing consistently in OFBiz. We could say that at the moment the OFBiz APIs and in general the framework code is fluid and could change even if this can cause backward incompatibilities. However the project/community puts some effort in trying to not cause backward incompatibilities between releases in the same release branch; on the other hand it is currently accepted that from a release branch to the next there could be incompatibilities even without the implementation of a deprecation pattern. It will be easier to implement a formal deprecation pattern, as you recommend, when we will have a separate release for the framework but for now we should not bring back code just to implement/enforce it. base/json/JSON has been removed, with no deprecation window --- Key: OFBIZ-6270 URL: https://issues.apache.org/jira/browse/OFBIZ-6270 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: Trunk, 12.04.04 Reporter: Adam Heath Assignee: Adam Heath Priority: Critical The antlr-based json parser(at org.ofbiz.base.json.JSON.cc) was removed last October(2014-10-27). However, no backwards-compatible class was left in place, with a proper @Deprecation tag applied. The proper approach should have been to leave the class in place, adding @Deprecation, and leaving the json-lib.jar in place. Then, after one successful release, removing the actual code. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-6268) Improve Start.java Component Loading
[ https://issues.apache.org/jira/browse/OFBIZ-6268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14504688#comment-14504688 ] Adrian Crum commented on OFBIZ-6268: The start component has many dependencies on base - there is no way to avoid that. Keep in mind that start used to be IN base. No changes have been made to the class loader tree. Improve Start.java Component Loading Key: OFBIZ-6268 URL: https://issues.apache.org/jira/browse/OFBIZ-6268 Project: OFBiz Issue Type: Improvement Components: framework Affects Versions: Upcoming Branch Reporter: Adrian Crum Priority: Minor Attachments: OFBIZ-6268.patch The current code for loading components parses configuration files twice. This issue is intended for review of code improvements. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-6268) Improve Start.java Component Loading
[ https://issues.apache.org/jira/browse/OFBIZ-6268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14504702#comment-14504702 ] Jacopo Cappellato commented on OFBIZ-6268: -- Moreover, the code that you have removed was honoring the classpath entries defined in the base component (ofbiz-component.xml) rather than just relying in the folder layout of it. Improve Start.java Component Loading Key: OFBIZ-6268 URL: https://issues.apache.org/jira/browse/OFBIZ-6268 Project: OFBiz Issue Type: Improvement Components: framework Affects Versions: Upcoming Branch Reporter: Adrian Crum Priority: Minor Attachments: OFBIZ-6268.patch The current code for loading components parses configuration files twice. This issue is intended for review of code improvements. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: move to git.
On 20 Apr 2015, at 23:21, Pierre Smits pierre.sm...@gmail.com wrote: Quoting: We are also prepared to be assertive regarding this situation. If the project does not move to GIT then Brainfood is willing to participate in a consortium of organizations that will peer with each other to share updates to the master branch for their local OFBiz repository. Such an arrangement will, effectively, result in a distributed master repository image. Thanks Ean for the position of *Brainfood* in this position. It comes across as 'Do it our way, or else'. You are free to make such statements and when followed through there will be consequences. For all participating in this project. One I can see standing out clearly is: no more participation in/contribution from the employees of Brainfood and from the other companies in that consortium back into the project. That's not at all what I get from Ean's comments. The magic of a community-driven project is that people can collaborate on anything they want, within the scope of the main project or as side projects. If the main project doesn't provide something desired, then it is perfectly appropriate for others to collaborate on that... better than doing it totally isolated. What Ean is talking about ties in with the general idea of distributed source management and distributed development. The general idea is that there may be many forks of the main source repo, potentially with various branches for different improvements and changes. These are generally made available publicly, like public GitHub forks of other public repositories (though with git they can be hosted anywhere). Those who make changes can request that particular changes be pulled into upstream repositories and then those who maintain the upstream repos (or the main project repo if it bubbles up that high) can review them and pull the changes if desired. Those who maintain upstream repos can also look around for useful changes in forked repos and pull them in as desired. Others who run their own forks can pull in changes from peer repositories too. It may seem like chaos to have forks and changes spread all over the place... but that isn't caused by the distributed source management approach, it's just made visible and clear by the approach. Right now this exists on a large scale for OFBiz, tons of forks and changes in them, but they are mostly not visible or publicly available so there is no way for OFBiz committers to pull changes from other repos... they basically have to be extracted into a patch file and submitted through a Jira issue. In other words, the chaos exists and the distributed source management enabled by git just makes it easier to track it all and tame it a bit. On a side note, this is one of the reasons I have concerns about making Moqui and related projects part of the ASF: the ASF community approach doesn't fit very well with this distributed source management model (pull requests are discouraged, all contributions should go through Jira issues... though I don't know that this is a strict policy). -David If that is going to happen, I will say: 'I thank you for all the contributions you did to the project'. And I will check in my sentiments at the door. I do hope that if you do you also resign totally from this project. I rather have the community comes to its decision based on sound/valid arguments, not (veiled) threats. Best regards, Pierre Smits *ORRTIZ.COM http://www.orrtiz.com* Services Solutions for Cloud- Based Manufacturing, Professional Services and Retail Trade http://www.orrtiz.com On Tue, Apr 21, 2015 at 2:08 AM, Ean Schuessler e...@brainfood.com wrote: - Original Message - From: Jacques Le Roux jacques.le.r...@les7arts.com Subject: Re: move to git. Like Adrian and mostly for the same reasons, I don't believe we need Git. But there is one other major reason which has already been discussed in the other common ASF MLs. As Taher exulted, it's possible to create local branches. So people are able to do a lot of work alone without exchanging before committing or submitting. It will certainly not help to have this possibility. I disagree. It is useful in many situations for OFBiz developers to create a local repository that is not globally shared. Some customers may even require such a situation for security or legal reasons. Remember our recent discussion on the lack or core commits reviews. With Git you end with commits bursts or big patches and it's then hard to review and too late to share ideas. So unlike Adrian, I'm even strongly against it. I will not hesitate to use a -1 if necessary! We are also prepared to be assertive regarding this situation. If the project does not move to GIT then Brainfood is willing to participate in a consortium of organizations that will peer with each other to share updates to the master branch for their local
Re: move to git.
Le 21/04/2015 12:02, David E. Jones a écrit : On 20 Apr 2015, at 23:21, Pierre Smits pierre.sm...@gmail.com wrote: Quoting: We are also prepared to be assertive regarding this situation. If the project does not move to GIT then Brainfood is willing to participate in a consortium of organizations that will peer with each other to share updates to the master branch for their local OFBiz repository. Such an arrangement will, effectively, result in a distributed master repository image. Thanks Ean for the position of *Brainfood* in this position. It comes across as 'Do it our way, or else'. You are free to make such statements and when followed through there will be consequences. For all participating in this project. One I can see standing out clearly is: no more participation in/contribution from the employees of Brainfood and from the other companies in that consortium back into the project. That's not at all what I get from Ean's comments. The magic of a community-driven project is that people can collaborate on anything they want, within the scope of the main project or as side projects. If the main project doesn't provide something desired, then it is perfectly appropriate for others to collaborate on that... better than doing it totally isolated. What Ean is talking about ties in with the general idea of distributed source management and distributed development. The general idea is that there may be many forks of the main source repo, potentially with various branches for different improvements and changes. These are generally made available publicly, like public GitHub forks of other public repositories (though with git they can be hosted anywhere). Those who make changes can request that particular changes be pulled into upstream repositories and then those who maintain the upstream repos (or the main project repo if it bubbles up that high) can review them and pull the changes if desired. Those who maintain upstream repos can also look around for useful changes in forked repos and pull them in as desired. Others who run their own forks can pull in changes from peer repositories too. It may seem like chaos to have forks and changes spread all over the place... but that isn't caused by the distributed source management approach, it's just made visible and clear by the approach. Right now this exists on a large scale for OFBiz, tons of forks and changes in them, but they are mostly not visible or publicly available so there is no way for OFBiz committers to pull changes from other repos... they basically have to be extracted into a patch file and submitted through a Jira issue. In other words, the chaos exists and the distributed source management enabled by git just makes it easier to track it all and tame it a bit. On a side note, this is one of the reasons I have concerns about making Moqui and related projects part of the ASF: the ASF community approach doesn't fit very well with this distributed source management model (pull requests are discouraged, all contributions should go through Jira issues... though I don't know that this is a strict policy). -David Interesting David, it can be compared to the OFBiz-France association effort to leverage the Nereides addons and addons manager. I let aside the licenses issues, as long as it's no part of a released package there are no problems. What do you think OFBiz-France members? Jacques If that is going to happen, I will say: 'I thank you for all the contributions you did to the project'. And I will check in my sentiments at the door. I do hope that if you do you also resign totally from this project. I rather have the community comes to its decision based on sound/valid arguments, not (veiled) threats. Best regards, Pierre Smits *ORRTIZ.COM http://www.orrtiz.com* Services Solutions for Cloud- Based Manufacturing, Professional Services and Retail Trade http://www.orrtiz.com On Tue, Apr 21, 2015 at 2:08 AM, Ean Schuessler e...@brainfood.com wrote: - Original Message - From: Jacques Le Roux jacques.le.r...@les7arts.com Subject: Re: move to git. Like Adrian and mostly for the same reasons, I don't believe we need Git. But there is one other major reason which has already been discussed in the other common ASF MLs. As Taher exulted, it's possible to create local branches. So people are able to do a lot of work alone without exchanging before committing or submitting. It will certainly not help to have this possibility. I disagree. It is useful in many situations for OFBiz developers to create a local repository that is not globally shared. Some customers may even require such a situation for security or legal reasons. Remember our recent discussion on the lack or core commits reviews. With Git you end with commits bursts or big patches and it's then hard to review and too late to share ideas. So unlike Adrian, I'm even strongly against it. I will not hesitate to use a -1 if
[jira] [Commented] (OFBIZ-6085) Add support for production run inventory tracking
[ https://issues.apache.org/jira/browse/OFBIZ-6085?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14505062#comment-14505062 ] Christian Carlow commented on OFBIZ-6085: - Pierre, TimeEntry was extended to act as InventoryItemDetail does for InventoryItem. The quantityProduced and quantityRejected fields allow for the entry to be reverted similar to InventoryItemDetail and have it update the corresponding task quantityProduced and quantityRejected. InventoryItemDetail alone is insufficient for providing the WorkEffort details. If the user doesn't choose a facilityIdTo in the declaration form then only the TimeEntry is created without tiggering the inventoryTransfer that creates the InventoryItemDetails. The timeEntryId field was added to InventoryItemDetail so the transfer information could be determined. For example, if a declaration time entry was created to move 1 from A to B and a second to move 2 from A to C, InventoryItemDetail.timeEntryId allows the second move to be reverted from C to A. InventoryItemDetail.workEffortId is insufficient because it doesn't support such reversion functionality nor the ability to determine which timeEntry and therefore party was responsible for the move. I'm not very familiar with OFBiz OLAP but am willing to dedicate time to extending this functionality to it such as the ProductionRunFact entity. However, it seems the existing functionality is still needed regardless. As for potential confusion of operators/users of OFBiz, this patch simply adds another form at the bottom of the page that lists the details of each declaration at the bottom of the page. It basically allows for the old functionality to work exactly the same it just creates timeEntries for each declaration. Perhaps a more acceptable solution would be to make the timeEntry functionality optional? Add support for production run inventory tracking - Key: OFBIZ-6085 URL: https://issues.apache.org/jira/browse/OFBIZ-6085 Project: OFBiz Issue Type: Improvement Components: manufacturing Affects Versions: Trunk Reporter: Christian Carlow Assignee: Pierre Smits Attachments: OFBIZ-6085.patch Production run inventory tracking seems worthy of support so that production managers can get an idea of the department work load. InventoryItemDetails should be created during production run declarations so that the material that was stocked out for the production run can be tracked while it is being manufacturing into the good. Essentially is would be like stock moves or inventory xfers occuring within the production runs for the task fixed asset facilities/locations. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-6085) Add support for production run inventory tracking
[ https://issues.apache.org/jira/browse/OFBIZ-6085?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14505068#comment-14505068 ] Pierre Smits commented on OFBIZ-6085: - By the way, and in case you were wondering: inspection related to manufacturing and inventory is covered... * the activity - WorkEffort * the time spent - TimeSheet and TimeEntry * the result - production run declaration - InventoryItem and InventoryItemDetail * the report - Content Add support for production run inventory tracking - Key: OFBIZ-6085 URL: https://issues.apache.org/jira/browse/OFBIZ-6085 Project: OFBiz Issue Type: Improvement Components: manufacturing Affects Versions: Trunk Reporter: Christian Carlow Assignee: Pierre Smits Attachments: OFBIZ-6085.patch Production run inventory tracking seems worthy of support so that production managers can get an idea of the department work load. InventoryItemDetails should be created during production run declarations so that the material that was stocked out for the production run can be tracked while it is being manufacturing into the good. Essentially is would be like stock moves or inventory xfers occuring within the production runs for the task fixed asset facilities/locations. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (OFBIZ-6085) Add support for production run inventory tracking
[ https://issues.apache.org/jira/browse/OFBIZ-6085?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14505062#comment-14505062 ] Christian Carlow edited comment on OFBIZ-6085 at 4/21/15 2:58 PM: -- Pierre, TimeEntry was extended to act as InventoryItemDetail does for InventoryItem. The quantityProduced and quantityRejected fields allow for the entry to be reverted similar to InventoryItemDetail and have it update the corresponding task quantityProduced and quantityRejected. InventoryItemDetail alone is insufficient for providing the WorkEffort details. If the user doesn't choose a facilityIdTo in the declaration form then only the TimeEntry is created without tiggering the inventoryTransfer that creates the InventoryItemDetails. The timeEntryId field was added to InventoryItemDetail so the transfer information could be determined. For example, if a declaration time entry was created to move 1 from A to B and a second to move 2 from A to C, InventoryItemDetail.timeEntryId allows the second move to be reverted from C to A. InventoryItemDetail.workEffortId is insufficient because it doesn't support such reversion functionality nor the ability to determine which timeEntry and therefore party was responsible for the move. I'm not very familiar with OFBiz OLAP but am willing to dedicate time to extending this functionality to it such as the ProductionRunFact entity. However, it seems the existing functionality is still needed regardless. As for potential confusion of operators/users of OFBiz, this patch simply adds another form at the bottom of the page that lists the details of each declaration. It basically allows for the old functionality to work exactly the same it just creates timeEntries for each declaration. Perhaps a more acceptable solution would be to make the timeEntry functionality optional? was (Author: ofbizzer): Pierre, TimeEntry was extended to act as InventoryItemDetail does for InventoryItem. The quantityProduced and quantityRejected fields allow for the entry to be reverted similar to InventoryItemDetail and have it update the corresponding task quantityProduced and quantityRejected. InventoryItemDetail alone is insufficient for providing the WorkEffort details. If the user doesn't choose a facilityIdTo in the declaration form then only the TimeEntry is created without tiggering the inventoryTransfer that creates the InventoryItemDetails. The timeEntryId field was added to InventoryItemDetail so the transfer information could be determined. For example, if a declaration time entry was created to move 1 from A to B and a second to move 2 from A to C, InventoryItemDetail.timeEntryId allows the second move to be reverted from C to A. InventoryItemDetail.workEffortId is insufficient because it doesn't support such reversion functionality nor the ability to determine which timeEntry and therefore party was responsible for the move. I'm not very familiar with OFBiz OLAP but am willing to dedicate time to extending this functionality to it such as the ProductionRunFact entity. However, it seems the existing functionality is still needed regardless. As for potential confusion of operators/users of OFBiz, this patch simply adds another form at the bottom of the page that lists the details of each declaration at the bottom of the page. It basically allows for the old functionality to work exactly the same it just creates timeEntries for each declaration. Perhaps a more acceptable solution would be to make the timeEntry functionality optional? Add support for production run inventory tracking - Key: OFBIZ-6085 URL: https://issues.apache.org/jira/browse/OFBIZ-6085 Project: OFBiz Issue Type: Improvement Components: manufacturing Affects Versions: Trunk Reporter: Christian Carlow Assignee: Pierre Smits Attachments: OFBIZ-6085.patch Production run inventory tracking seems worthy of support so that production managers can get an idea of the department work load. InventoryItemDetails should be created during production run declarations so that the material that was stocked out for the production run can be tracked while it is being manufacturing into the good. Essentially is would be like stock moves or inventory xfers occuring within the production runs for the task fixed asset facilities/locations. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-6267) Replace ProductionRun.fo with widgets
[ https://issues.apache.org/jira/browse/OFBIZ-6267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14505072#comment-14505072 ] Jacques Le Roux commented on OFBIZ-6267: Thanks for the effort Christian, appreciated :) Replace ProductionRun.fo with widgets - Key: OFBIZ-6267 URL: https://issues.apache.org/jira/browse/OFBIZ-6267 Project: OFBiz Issue Type: Improvement Components: manufacturing Reporter: Christian Carlow Assignee: Nicolas Malin Attachments: OFBIZ-6267.patch -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: move to git.
Comments inline. From: David E. Jones d...@me.com Subject: Re: move to git. It may seem like chaos to have forks and changes spread all over the place... but that isn't caused by the distributed source management approach, it's just made visible and clear by the approach. Right now this exists on a large scale for OFBiz, tons of forks and changes in them, but they are mostly not visible or publicly available so there is no way for OFBiz committers to pull changes from other repos... they basically have to be extracted into a patch file and submitted through a Jira issue. In other words, the chaos exists and the distributed source management enabled by git just makes it easier to track it all and tame it a bit. Precisely so. With GIT the chaos stays at its source until other players decide it is worth pulling into their copies of the world. With SVN you get the chaos of every committer whether you want it or not. (Note: this includes Brainfood's chaos for anyone who wants to mischaracterize my comments as an attack) On a side note, this is one of the reasons I have concerns about making Moqui and related projects part of the ASF: the ASF community approach doesn't fit very well with this distributed source management model (pull requests are discouraged, all contributions should go through Jira issues... though I don't know that this is a strict policy). At Apachecon, Apache's engineering and corporate leadership advised me that we could move to using OFBiz to manage our issues instead of JIRA if we so desire.
Re: move to git.
Quoting: At Apachecon, Apache's engineering and corporate leadership advised me that we could move to using OFBiz to manage our issues instead of JIRA if we so desire. If we want to explore that path, I suggest we do that in a separate thread. Best regards, Pierre Smits *ORRTIZ.COM http://www.orrtiz.com* Services Solutions for Cloud- Based Manufacturing, Professional Services and Retail Trade http://www.orrtiz.com On Tue, Apr 21, 2015 at 3:35 PM, Ean Schuessler e...@brainfood.com wrote: Comments inline. From: David E. Jones d...@me.com Subject: Re: move to git. It may seem like chaos to have forks and changes spread all over the place... but that isn't caused by the distributed source management approach, it's just made visible and clear by the approach. Right now this exists on a large scale for OFBiz, tons of forks and changes in them, but they are mostly not visible or publicly available so there is no way for OFBiz committers to pull changes from other repos... they basically have to be extracted into a patch file and submitted through a Jira issue. In other words, the chaos exists and the distributed source management enabled by git just makes it easier to track it all and tame it a bit. Precisely so. With GIT the chaos stays at its source until other players decide it is worth pulling into their copies of the world. With SVN you get the chaos of every committer whether you want it or not. (Note: this includes Brainfood's chaos for anyone who wants to mischaracterize my comments as an attack) On a side note, this is one of the reasons I have concerns about making Moqui and related projects part of the ASF: the ASF community approach doesn't fit very well with this distributed source management model (pull requests are discouraged, all contributions should go through Jira issues... though I don't know that this is a strict policy). At Apachecon, Apache's engineering and corporate leadership advised me that we could move to using OFBiz to manage our issues instead of JIRA if we so desire.
[jira] [Commented] (OFBIZ-6085) Add support for production run inventory tracking
[ https://issues.apache.org/jira/browse/OFBIZ-6085?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14505083#comment-14505083 ] Pierre Smits commented on OFBIZ-6085: - Re: time registration functionality... We have an app for that (and on top of the workeffort component. It is the myportal solution. Are you sure we (the whole of the OFBiz community) want the user experience regarding the Manufacturing application to become as diluted with screens/forms/functions as some others are? I, for one, am not keen on that. Add support for production run inventory tracking - Key: OFBIZ-6085 URL: https://issues.apache.org/jira/browse/OFBIZ-6085 Project: OFBiz Issue Type: Improvement Components: manufacturing Affects Versions: Trunk Reporter: Christian Carlow Assignee: Pierre Smits Attachments: OFBIZ-6085.patch Production run inventory tracking seems worthy of support so that production managers can get an idea of the department work load. InventoryItemDetails should be created during production run declarations so that the material that was stocked out for the production run can be tracked while it is being manufacturing into the good. Essentially is would be like stock moves or inventory xfers occuring within the production runs for the task fixed asset facilities/locations. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: move to git.
Le 21/04/2015 16:00, Pierre Smits a écrit : Quoting: At Apachecon, Apache's engineering and corporate leadership advised me that we could move to using OFBiz to manage our issues instead of JIRA if we so desire. If we want to explore that path, I suggest we do that in a separate thread. Please don't, so we would not only move to Git and/or Maven and/or Moqui but while doing so we would also compete with Jira? :-o Jacques Best regards, Pierre Smits *ORRTIZ.COM http://www.orrtiz.com* Services Solutions for Cloud- Based Manufacturing, Professional Services and Retail Trade http://www.orrtiz.com On Tue, Apr 21, 2015 at 3:35 PM, Ean Schuessler e...@brainfood.com wrote: Comments inline. From: David E. Jones d...@me.com Subject: Re: move to git. It may seem like chaos to have forks and changes spread all over the place... but that isn't caused by the distributed source management approach, it's just made visible and clear by the approach. Right now this exists on a large scale for OFBiz, tons of forks and changes in them, but they are mostly not visible or publicly available so there is no way for OFBiz committers to pull changes from other repos... they basically have to be extracted into a patch file and submitted through a Jira issue. In other words, the chaos exists and the distributed source management enabled by git just makes it easier to track it all and tame it a bit. Precisely so. With GIT the chaos stays at its source until other players decide it is worth pulling into their copies of the world. With SVN you get the chaos of every committer whether you want it or not. (Note: this includes Brainfood's chaos for anyone who wants to mischaracterize my comments as an attack) On a side note, this is one of the reasons I have concerns about making Moqui and related projects part of the ASF: the ASF community approach doesn't fit very well with this distributed source management model (pull requests are discouraged, all contributions should go through Jira issues... though I don't know that this is a strict policy). At Apachecon, Apache's engineering and corporate leadership advised me that we could move to using OFBiz to manage our issues instead of JIRA if we so desire.
[jira] [Updated] (OFBIZ-6085) Add support for production run inventory tracking
[ https://issues.apache.org/jira/browse/OFBIZ-6085?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Carlow updated OFBIZ-6085: Attachment: (was: OFBIZ-6085.patch) Add support for production run inventory tracking - Key: OFBIZ-6085 URL: https://issues.apache.org/jira/browse/OFBIZ-6085 Project: OFBiz Issue Type: Improvement Components: manufacturing Affects Versions: Trunk Reporter: Christian Carlow Assignee: Pierre Smits Attachments: OFBIZ-6085.patch Production run inventory tracking seems worthy of support so that production managers can get an idea of the department work load. InventoryItemDetails should be created during production run declarations so that the material that was stocked out for the production run can be tracked while it is being manufacturing into the good. Essentially is would be like stock moves or inventory xfers occuring within the production runs for the task fixed asset facilities/locations. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OFBIZ-6085) Add support for production run inventory tracking
[ https://issues.apache.org/jira/browse/OFBIZ-6085?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Carlow updated OFBIZ-6085: Attachment: OFBIZ-6085.patch Add support for production run inventory tracking - Key: OFBIZ-6085 URL: https://issues.apache.org/jira/browse/OFBIZ-6085 Project: OFBiz Issue Type: Improvement Components: manufacturing Affects Versions: Trunk Reporter: Christian Carlow Assignee: Pierre Smits Attachments: OFBIZ-6085.patch Production run inventory tracking seems worthy of support so that production managers can get an idea of the department work load. InventoryItemDetails should be created during production run declarations so that the material that was stocked out for the production run can be tracked while it is being manufacturing into the good. Essentially is would be like stock moves or inventory xfers occuring within the production runs for the task fixed asset facilities/locations. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OFBIZ-6267) Replace ProductionRun.fo with widgets
[ https://issues.apache.org/jira/browse/OFBIZ-6267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Carlow updated OFBIZ-6267: Attachment: OFBIZ-6267.patch The attached patch was extracted from OFBIZ-6085. Replace ProductionRun.fo with widgets - Key: OFBIZ-6267 URL: https://issues.apache.org/jira/browse/OFBIZ-6267 Project: OFBiz Issue Type: Improvement Components: manufacturing Reporter: Christian Carlow Assignee: Nicolas Malin Attachments: OFBIZ-6267.patch -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: move to git.
Comments inline.
From: Pierre Smits pierre.sm...@gmail.com
Subject: Re: move to git.
Quoting:
We are also prepared to be assertive regarding this situation.
SNIP
Thanks Ean for the position of *Brainfood* in this position. It comes
across as 'Do it our way, or else'. You are free to make such statements
and when followed through there will be consequences. For all participating
in this project. One I can see standing out clearly is: no more
participation in/contribution from the employees of Brainfood and from the
other companies in that consortium back into the project.
If that is going to happen, I will say: 'I thank you for all the
contributions you did to the project'. And I will check in my sentiments at
the door. I do hope that if you do you also resign totally from this
project.
I believe what I said was we'll do it our way even if you continue to do it
your way. I'm not sure what the or else part of my message was. I would ask
you to explain that to me but I'm not sure its important to the discussion.
I rather have the community comes to its decision based on sound/valid
arguments, not (veiled) threats.
There were no threats in my message. A threat might read like no participation
in/contribution from {insert group here} will be allowed if they try to do
something without my permission.
The Apache Way is to be nice and I think it would be nice if people could
pursue their own ideas about how to improve the project as long as they do not
coerce other members.
[jira] [Commented] (OFBIZ-6085) Add support for production run inventory tracking
[ https://issues.apache.org/jira/browse/OFBIZ-6085?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14504972#comment-14504972 ] Pierre Smits commented on OFBIZ-6085: - Christian, It seems you're pulling more and more together into this, so that many issues are addressed: inspection, quality measurements, WIP, time registrations, etc... For review and acceptance purposes the distributed/separated approach is easier, swallowing the elephant in one piece is way harder than piece by piece. Apart from the above, please indulge me for a moment to explain my viewpoint on the whole of manufacturing mgt with OFBiz (issues - and comments thereon - registered by others, you and me) in relation to the various entities in other applications/components and the DRMBs (1 and 2). Executing a production run (manufacturing) is in essence a simple set of processes, triggered by others (e.g. order and/or requirements registration - and their related entities), governed/directed by again others (defining schemas,tasks and BoMs) effecting yet another set of other processes and entities (time registrations, inventory items). This simplicity is fairly well implemented in OFBiz, while at the same time allowing for some of the required complexities individual companies might have. As we can surmise, we are not there yet regarding the OSFA (One Size Fits All). But with your help we are getting to something that can be applied to your specific needs as well, that's for sure. Now, on to the details (given the above, and reiterating a bit more - my apologies for that): # the WorkEffort entity is for the registration of the activity (schema, schema task, production and production run task). It relates to the resource (person, production equipment et all) and the facility. # the InventoryItem entity is for the registration of the goods (raw material, intermediate, end product, waste, rejects, etc) going in and coming out of the the activity. And it relates to the activity, the facility and worker (the latter somehow). # the TimeEntry is for registration of time spent on the activity. And it relates to the resource (person or other production resource). What you are trying to achieve is extending existing entity elements (I must confess: in my assertion) in order to have more insights in the whole down to the nitty-gritty details. This, is for sure, the domain of data warehousing/data analysis/reporting. But how you want to achieve the latter should not be done by extending the former in that way (and that much). To give as example(s): * you're proposing to change the TimeEntry entity by including elements for quantity produced and quantity rejected. That is not needed as quantity produced (and rejected) can be registered through the entities in the product component. * you're proposing to change the InventoryItemDetail entity to include the Id of the TimeEntry record to have a relation with the elements stated above and the time spent. That is also not needed as there is a relation to TimeEntry records via the association of the WorkEffort record. Now, the aspects to bring it all together (more/better) for data warehousing/analysis and reporting (according to DRMB vol 2, page 70 and following) is the Star Schema for Manufacturing feeding into ofbizolap (the targeted db) as opposed to ofbiz (for transactions) and pre-eminently the 'ProductionRunFact' entity. Another aspect (more high level) to consider is this: if we were to apply the associated patch as is, how much more would it complicate/confuse other operators/users of OFBiz manufacturing? Way more, I surmise. Can it be configured to work in that other way for that other kind of user? At the moment (given current feature/requirement set) it can't. And with the implementation of the associated patch it can't either... On the whole a degradation in the adoption potential of OFBiz in general, and of OFBiz Manufacturing in particular. (I fear). Best regards, Pierre Add support for production run inventory tracking - Key: OFBIZ-6085 URL: https://issues.apache.org/jira/browse/OFBIZ-6085 Project: OFBiz Issue Type: Improvement Components: manufacturing Affects Versions: Trunk Reporter: Christian Carlow Assignee: Pierre Smits Attachments: OFBIZ-6085.patch Production run inventory tracking seems worthy of support so that production managers can get an idea of the department work load. InventoryItemDetails should be created during production run declarations so that the material that was stocked out for the production run can be tracked while it is being manufacturing into the good. Essentially is would be like stock moves or inventory xfers occuring within the production runs for the task
Re: move to git.
Le 21/04/2015 02:26, Adam Heath a écrit : On 04/20/2015 04:12 AM, Jacques Le Roux wrote: Like Adrian and mostly for the same reasons, I don't believe we need Git. But there is one other major reason which has already been discussed in the other common ASF MLs. As Taher exulted, it's possible to create local branches. So people are able to do a lot of work alone without exchanging before committing or submitting. It will certainly not help to have this possibility. Remember our recent discussion on the lack or core commits reviews. With Git you end with commits bursts or big patches and it's then hard to review and too late to share ideas. I take exception to this; I believe you are referring to my commit bursts, in times past. Aka, 10-15 commits get added to svn in under a minute. Git allows me to create a new feature, initially as a single large commit(or several large commits). Then, using the rebase feature, I pull out very small changes, that are easy to understand, and digest. I then might commit those as completely separate fixes/feature-additions, which then get reviewed. I then wait a bit, and rebase my big work on top of the new trunk. Eventually, I get the history to such a point that I feel that the series of commits are an easy to understand progression. At that point, I commit the entire set to svn. Note, that I run the entire set of test cases(as they exist at that point) against each and every single commit, before I send them off. Having each commit separate, allows for each change to be looked at in isolation. If they were all combined into one, then it would be much more difficult to review. If the number of commits at once is the problem, then I don't follow. Spreading each commit out over several hours still won't cause anything to get reviewed. I can see your point and it's difficult to not agree. I though have still a feeling that with Git spirit less things will be shared and discussed before being committed Jacques
Re: move to git.
Quoting: they basically have to be extracted into a patch file and submitted through a Jira issue Which is a good approach with respect to improvements of the other kind (improvements, not bug fixes) as they than can be assessed, regarding applicability in light of the direction of the project and its works, by all in the community. And not through some filtering mech of the various subsets (of controlling/directing/dictating entities) of the community before the contribution of the individual gets to the project. It is the amalgamation/aggregation in the hierarchy described (by David) that should be of more concern than the mere technical aspects of the tool applied. Best regards, Pierre Smits *ORRTIZ.COM http://www.orrtiz.com* Services Solutions for Cloud- Based Manufacturing, Professional Services and Retail Trade http://www.orrtiz.com On Tue, Apr 21, 2015 at 12:19 PM, Jacques Le Roux jacques.le.r...@les7arts.com wrote: Le 21/04/2015 12:02, David E. Jones a écrit : On 20 Apr 2015, at 23:21, Pierre Smits pierre.sm...@gmail.com wrote: Quoting: We are also prepared to be assertive regarding this situation. If the project does not move to GIT then Brainfood is willing to participate in a consortium of organizations that will peer with each other to share updates to the master branch for their local OFBiz repository. Such an arrangement will, effectively, result in a distributed master repository image. Thanks Ean for the position of *Brainfood* in this position. It comes across as 'Do it our way, or else'. You are free to make such statements and when followed through there will be consequences. For all participating in this project. One I can see standing out clearly is: no more participation in/contribution from the employees of Brainfood and from the other companies in that consortium back into the project. That's not at all what I get from Ean's comments. The magic of a community-driven project is that people can collaborate on anything they want, within the scope of the main project or as side projects. If the main project doesn't provide something desired, then it is perfectly appropriate for others to collaborate on that... better than doing it totally isolated. What Ean is talking about ties in with the general idea of distributed source management and distributed development. The general idea is that there may be many forks of the main source repo, potentially with various branches for different improvements and changes. These are generally made available publicly, like public GitHub forks of other public repositories (though with git they can be hosted anywhere). Those who make changes can request that particular changes be pulled into upstream repositories and then those who maintain the upstream repos (or the main project repo if it bubbles up that high) can review them and pull the changes if desired. Those who maintain upstream repos can also look around for useful changes in forked repos and pull them in as desired. Others who run their own forks can pull in changes from peer repositories too. It may seem like chaos to have forks and changes spread all over the place... but that isn't caused by the distributed source management approach, it's just made visible and clear by the approach. Right now this exists on a large scale for OFBiz, tons of forks and changes in them, but they are mostly not visible or publicly available so there is no way for OFBiz committers to pull changes from other repos... they basically have to be extracted into a patch file and submitted through a Jira issue. In other words, the chaos exists and the distributed source management enabled by git just makes it easier to track it all and tame it a bit. On a side note, this is one of the reasons I have concerns about making Moqui and related projects part of the ASF: the ASF community approach doesn't fit very well with this distributed source management model (pull requests are discouraged, all contributions should go through Jira issues... though I don't know that this is a strict policy). -David Interesting David, it can be compared to the OFBiz-France association effort to leverage the Nereides addons and addons manager. I let aside the licenses issues, as long as it's no part of a released package there are no problems. What do you think OFBiz-France members? Jacques If that is going to happen, I will say: 'I thank you for all the contributions you did to the project'. And I will check in my sentiments at the door. I do hope that if you do you also resign totally from this project. I rather have the community comes to its decision based on sound/valid arguments, not (veiled) threats. Best regards, Pierre Smits *ORRTIZ.COM http://www.orrtiz.com* Services Solutions for Cloud- Based Manufacturing, Professional Services and Retail Trade http://www.orrtiz.com On Tue, Apr 21, 2015 at 2:08 AM, Ean Schuessler
Re: move to git.
Le 21/04/2015 11:08, Adrian Crum a écrit : Taher, Nothing in your reply is new or different. People have been doing that for years with Subversion. Git did not invent local repositories. Connecting a local Git repository to the OFBiz Subversion repository is a problem for some, that is why we are having this discussion. So far, two proposals have been made: 1. Switch the OFBiz project to Git. 2. Host a separate Git repo that is a copy of the OFBiz Subversion repo. How those proposals affect OFBiz developers: 1. Subversion users must switch to Git clients and learn Git. 2. Git users can access the project through the Git repo, Subversion users continue using Subversion with the main OFBiz repo. Switching the main repo to Git does not add anything to the project itself. As I said before, Subversion handles our simple needs just fine. If Jacopo said something like, Managing our releases is impossible with Subversion, we really need to switch to Git - then we wouldn't be having this discussion, it would just happen because the need for the switch is obvious. But Jacopo is not saying that, and we don't have a problem using Subversion to manage the project. I don't remember Jacopo proposed to move to Git, it was Hans, then Taher, Adam and Ean seconded. I guess Taher, AntWeb and Brainfood are using Git and they would like to see OFBiz using it as well. I have been using a Git repo for a custom project. I simply put the OFBiz .svn in the Git working copy and repo et voilà. I had the best of both world, I could easily backport my contributions in OFBiz. It's also very convenient for other reasons. I must admit it's not available for non committers who have to create patches, nothing new.. Jacques Adrian Crum Sandglass Software www.sandglass-software.com On 4/21/2015 9:19 AM, Taher Alkhateeb wrote: Hi Jacques and all, I think that sharing more than anything is a reason why git has an advantage. The distributed system means that every developer is a repository and therefore you can have endless chains of code propagation up to a committer. Just imagine a scenario like the following - A team is composed of people working on a major task - Two of the members (A and B) have their own sub-teams - There is exchange of code between the sub-teams, the major team and the project committer. Furthermore, the sub-teams need to pull updated data from the main repository of the project. So you have two integrators at the sub-team level and one integrator at the top team level plus a project committer. Sometimes, I want to pull code from the sub-team. Sometimes I want to pull code from the _other_ team. Then maybe I want to _merge_ work from both teams and run all tests. Then I want to clean the commit log with git rebase to cleanup the history into major commits to submit to the project committer. Now the project owner does not know / trust me but he knows / trusts you. And you in turn trust me so you can accept my commits. I cannot imagine how to implement the above without a distributed source code management system. Furthermore, it's important to note that ofbiz is not a closed proprietary project with a sacred repository hidden in the vault of some company. You _need_ contributions from others and you need to make it very easy and accessible. You need to have the ability for people to form teams and sub-teams to support you and your project by collaborating with each other without needing a committer. This is one of the main reasons for the massive success of the Linux Kernel where each of Linus Torvald's lieutenants is a committer for a sub-system with his/her own people they trust and work closely with. Some of this stuff is briefly shown in here http://www.git-scm.com/about/distributed I hope what I wrote is resonating with you and you're willing to give this idea a chance Taher Alkhateeb On Tue, Apr 21, 2015 at 10:23 AM, Jacques Le Roux jacques.le.r...@les7arts.com wrote: Le 21/04/2015 02:08, Ean Schuessler a écrit : - Original Message - From: Jacques Le Roux jacques.le.r...@les7arts.com Subject: Re: move to git. Like Adrian and mostly for the same reasons, I don't believe we need Git. But there is one other major reason which has already been discussed in the other common ASF MLs. As Taher exulted, it's possible to create local branches. So people are able to do a lot of work alone without exchanging before committing or submitting. It will certainly not help to have this possibility. I disagree. It is useful in many situations for OFBiz developers to create a local repository that is not globally shared. What about https://github.com/apache/ofbiz ? Some customers may even require such a situation for security or legal reasons. People can do what they want with OFBiz code on their side, sharing with the community is something else (and often harder) Jacques Remember our recent discussion on the lack or core commits reviews. With Git you end with
Re: move to git.
On Apr 21, 2015, at 11:23 AM, Jacques Le Roux jacques.le.r...@les7arts.com wrote: Switching the main repo to Git does not add anything to the project itself. As I said before, Subversion handles our simple needs just fine. If Jacopo said something like, Managing our releases is impossible with Subversion, we really need to switch to Git - then we wouldn't be having this discussion, it would just happen because the need for the switch is obvious. But Jacopo is not saying that, and we don't have a problem using Subversion to manage the project. I don't remember Jacopo proposed to move to Git, it was Hans, then Taher, Adam and Ean seconded. I guess Taher, AntWeb and Brainfood are using Git and they would like to see OFBiz using it as well. In fact I didn't express my opinion or preference. At Hotwax we use Git for all our projects and we are happy with it. But this doesn't mean that svn is bad or old or not a good tool for OFBiz. In fact, as I mentioned to Hans at ApacheCon, before discussing svn vs git as mere tools, it would be more interesting and useful to review/discuss the contribution/commit workflows that these tools can enable and see if there is a room for a better workflow for the project. Jacopo
Re: move to git.
Everyone is missing the point I am trying to make. I said, ***IF*** Jacopo said something like... As the OFBiz RM, ***IF*** Jacopo said he couldn't use Subversion to manage the OFBiz project, then the need to switch to something else would be obvious. I hope that clarifies my true meaning. Adrian Crum Sandglass Software www.sandglass-software.com On 4/21/2015 11:55 AM, Jacopo Cappellato wrote: On Apr 21, 2015, at 11:23 AM, Jacques Le Roux jacques.le.r...@les7arts.com wrote: Switching the main repo to Git does not add anything to the project itself. As I said before, Subversion handles our simple needs just fine. If Jacopo said something like, Managing our releases is impossible with Subversion, we really need to switch to Git - then we wouldn't be having this discussion, it would just happen because the need for the switch is obvious. But Jacopo is not saying that, and we don't have a problem using Subversion to manage the project. I don't remember Jacopo proposed to move to Git, it was Hans, then Taher, Adam and Ean seconded. I guess Taher, AntWeb and Brainfood are using Git and they would like to see OFBiz using it as well. In fact I didn't express my opinion or preference. At Hotwax we use Git for all our projects and we are happy with it. But this doesn't mean that svn is bad or old or not a good tool for OFBiz. In fact, as I mentioned to Hans at ApacheCon, before discussing svn vs git as mere tools, it would be more interesting and useful to review/discuss the contribution/commit workflows that these tools can enable and see if there is a room for a better workflow for the project. Jacopo
Re: move to git.
That's indeed what needs to be discussed and that why I asked OFBiz-France members opinions Jacques Le 21/04/2015 12:52, Pierre Smits a écrit : Sharing those improvements as patches attached to JIRA issues is a way better mechanism for exposure and review than through the distributed and competing search/find tools of today (Google et all) into all the distributed repositories or forks. Best regards, Pierre. Op dinsdag 21 april 2015 heeft Sharan Foga sharan.f...@gmail.com het volgende geschreven: Hi All I've been looking at some of what OFBiz France has done regarding addons for OFBiz . I think there are a lot of useful things that have been contributed by the community in general (not only OFBiz France) that are either sitting in forks or addons or just in Jira that haven't really been visible to the community. Making them visible gives the community more freedom and choice - whatever tool is used. Thanks Sharan On 21.4.2015 12:19, Jacques Le Roux wrote: Le 21/04/2015 12:02, David E. Jones a écrit : On 20 Apr 2015, at 23:21, Pierre Smits pierre.sm...@gmail.com wrote: Quoting: We are also prepared to be assertive regarding this situation. If the project does not move to GIT then Brainfood is willing to participate in a consortium of organizations that will peer with each other to share updates to the master branch for their local OFBiz repository. Such an arrangement will, effectively, result in a distributed master repository image. Thanks Ean for the position of *Brainfood* in this position. It comes across as 'Do it our way, or else'. You are free to make such statements and when followed through there will be consequences. For all participating in this project. One I can see standing out clearly is: no more participation in/contribution from the employees of Brainfood and from the other companies in that consortium back into the project. That's not at all what I get from Ean's comments. The magic of a community-driven project is that people can collaborate on anything they want, within the scope of the main project or as side projects. If the main project doesn't provide something desired, then it is perfectly appropriate for others to collaborate on that... better than doing it totally isolated. What Ean is talking about ties in with the general idea of distributed source management and distributed development. The general idea is that there may be many forks of the main source repo, potentially with various branches for different improvements and changes. These are generally made available publicly, like public GitHub forks of other public repositories (though with git they can be hosted anywhere). Those who make changes can request that particular changes be pulled into upstream repositories and then those who maintain the upstream repos (or the main project repo if it bubbles up that high) can review them and pull the changes if desired. Those who maintain upstream repos can also look around for useful changes in forked repos and pull them in as desired. Others who run their own forks can pull in changes from peer repositories too. It may seem like chaos to have forks and changes spread all over the place... but that isn't caused by the distributed source management approach, it's just made visible and clear by the approach. Right now this exists on a large scale for OFBiz, tons of forks and changes in them, but they are mostly not visible or publicly available so there is no way for OFBiz committers to pull changes from other repos... they basically have to be extracted into a patch file and submitted through a Jira issue. In other words, the chaos exists and the distributed source management enabled by git just makes it easier to track it all and tame it a bit. On a side note, this is one of the reasons I have concerns about making Moqui and related projects part of the ASF: the ASF community approach doesn't fit very well with this distributed source management model (pull requests are discouraged, all contributions should go through Jira issues... though I don't know that this is a strict policy). -David Interesting David, it can be compared to the OFBiz-France association effort to leverage the Nereides addons and addons manager. I let aside the licenses issues, as long as it's no part of a released package there are no problems. What do you think OFBiz-France members? Jacques If that is going to happen, I will say: 'I thank you for all the contributions you did to the project'. And I will check in my sentiments at the door. I do hope that if you do you also resign totally from this project. I rather have the community comes to its decision based on sound/valid arguments, not (veiled) threats. Best regards, Pierre Smits *ORRTIZ.COM http://www.orrtiz.com* Services Solutions for Cloud- Based Manufacturing, Professional Services and Retail Trade http://www.orrtiz.com On Tue, Apr 21, 2015 at 2:08 AM, Ean Schuessler e...@brainfood.com wrote: -
[jira] [Commented] (OFBIZ-6268) Improve Start.java Component Loading
[
https://issues.apache.org/jira/browse/OFBIZ-6268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14504792#comment-14504792
]
Jacopo Cappellato commented on OFBIZ-6268:
--
This is indeed a good point and a good idea for an improvement.
The current code that does this:
{code}
collectClasspathEntries(new File(home, framework), classPath,
libraryPath);
collectClasspathEntries(new File(home, applications), classPath,
libraryPath);
collectClasspathEntries(new File(home, specialpurpose), classPath,
libraryPath);
collectClasspathEntries(new File(home, hot-deploy), classPath,
libraryPath);
{code}
should instead look at the content of the component-loader file you mention; I
didn't think about it when I have implemented the code.
Improve Start.java Component Loading
Key: OFBIZ-6268
URL: https://issues.apache.org/jira/browse/OFBIZ-6268
Project: OFBiz
Issue Type: Improvement
Components: framework
Affects Versions: Upcoming Branch
Reporter: Adrian Crum
Priority: Minor
Attachments: OFBIZ-6268.patch
The current code for loading components parses configuration files twice.
This issue is intended for review of code improvements.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Re: move to git.
As far as I can see it, this whole discussion regarding GIT vs SVN (move to GIT), is dependent on and blocked by the perceptions of (and viewpoints on) the (in)clarity surrounding how we (as the contributing community) deal with code-changing contributions (CTR vs RTC/patches vs dumps). If we don’t deal with that first, I see blockers on the road forward every time we reiterate this GIT vs SVN discussion. Like it there were before and are now. It seems we (all) need a realignment and/or re-acceptance of our G C (of the GRC) in that area first. Best regards, Pierre Smits *ORRTIZ.COM http://www.orrtiz.com* Services Solutions for Cloud- Based Manufacturing, Professional Services and Retail Trade http://www.orrtiz.com On Tue, Apr 21, 2015 at 1:22 PM, Jacopo Cappellato jacopo.cappell...@hotwaxsystems.com wrote: On Apr 21, 2015, at 12:59 PM, Adrian Crum adrian.c...@sandglass-software.com wrote: Everyone is missing the point I am trying to make. I said, ***IF*** Jacopo said something like... As the OFBiz RM, ***IF*** Jacopo said he couldn't use Subversion to manage the OFBiz project, then the need to switch to something else would be obvious. I hope that clarifies my true meaning. Adrian Crum It was clear to me since your first message but I have replied to Jacques as I was starting to feel dragged (or, in the context of git, I should say pulled) into the mix :-) Jacopo
[jira] [Commented] (OFBIZ-6267) Replace ProductionRun.fo with widgets
[ https://issues.apache.org/jira/browse/OFBIZ-6267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14504883#comment-14504883 ] Pierre Smits commented on OFBIZ-6267: - I am equally inviting. Equally veiled. ;-) Replace ProductionRun.fo with widgets - Key: OFBIZ-6267 URL: https://issues.apache.org/jira/browse/OFBIZ-6267 Project: OFBiz Issue Type: Improvement Components: manufacturing Reporter: Christian Carlow Assignee: Nicolas Malin -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-6085) Add support for production run inventory tracking
[ https://issues.apache.org/jira/browse/OFBIZ-6085?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14505114#comment-14505114 ] Pierre Smits commented on OFBIZ-6085: - Re: triggered InventoryTransfer - Automatic? Have you taken into consideration that such requires approval? Consider the scenario where the two departments are located miles apart (different facilities - or even sub facilities on the same plot). Consider also the manager of department A not being the manager of department B. Re: User experience and optionality The best way to maximise the user experience regarding the optionality is through configuration. But like I said: are we (OFBiz) sure we want such aspects like time registration forms and others pulled from other components into Manufacturing, risking the potential dilution/degradation of the user experience/adoption potential? You can guess my viewpoint. Add support for production run inventory tracking - Key: OFBIZ-6085 URL: https://issues.apache.org/jira/browse/OFBIZ-6085 Project: OFBiz Issue Type: Improvement Components: manufacturing Affects Versions: Trunk Reporter: Christian Carlow Assignee: Pierre Smits Attachments: OFBIZ-6085.patch Production run inventory tracking seems worthy of support so that production managers can get an idea of the department work load. InventoryItemDetails should be created during production run declarations so that the material that was stocked out for the production run can be tracked while it is being manufacturing into the good. Essentially is would be like stock moves or inventory xfers occuring within the production runs for the task fixed asset facilities/locations. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: move to git.
On 21/04/2015 6:55 AM, Jacopo Cappellato wrote: On Apr 21, 2015, at 11:23 AM, Jacques Le Roux jacques.le.r...@les7arts.com wrote: Switching the main repo to Git does not add anything to the project itself. As I said before, Subversion handles our simple needs just fine. If Jacopo said something like, Managing our releases is impossible with Subversion, we really need to switch to Git - then we wouldn't be having this discussion, it would just happen because the need for the switch is obvious. But Jacopo is not saying that, and we don't have a problem using Subversion to manage the project. I don't remember Jacopo proposed to move to Git, it was Hans, then Taher, Adam and Ean seconded. I guess Taher, AntWeb and Brainfood are using Git and they would like to see OFBiz using it as well. In fact I didn't express my opinion or preference. At Hotwax we use Git for all our projects and we are happy with it. But this doesn't mean that svn is bad or old or not a good tool for OFBiz. In fact, as I mentioned to Hans at ApacheCon, before discussing svn vs git as mere tools, it would be more interesting and useful to review/discuss the contribution/commit workflows that these tools can enable and see if there is a room for a better workflow for the project. Jacopo I think that this is a very good summary of the issue. It appears to me that there is a fundamental shift of philosophy that Move to git is discussing rather than a tool switch. With git it is much easier to develop parallel products. I could chose to follow Jacopo's public repo or Ean's rather than the official OFBiz repo if I felt that they were doing things that I liked that were not being committed to the OFBiz repo. I could take changes from more than one repo if I felt that I could handle the integration workload and maintain a blended product. I could make changes and request that any other repo that wanted to have them, take them but I have no guarantee that Jacopo, Ean or OFBiz would accept them. I could use the Apache JIRA to document my patch or not. Clearly a JIRA issue would get more discussion and might cause me to revise my contribution or make it more likely to be accepted if the concensus is that it is a good thing. I could create my own issue tracking system and invite others to look there for my ideas. Each one of the versions could have its own release schedule. This is substantially different that the current situation and I think that Jacopo's suggested course of action of looking at the proposal as a question of workflow is a good idea. Underlying this discussion, there is a dissatisfaction with the workflow expressed by people who are not committers (in general). There are a lot of private forks of OFBiz already but most of the ones that show up here are based on the OFBiz trunk and are produced by committers who contribute back some of their local changes. In some ways, moving to a more distributed system, does help make OFBiz stronger. The keepers of the OFBiz repo have control as they do now about what changes get incorporated into the OFBiz trunk. Others can continue to use the contributions to the trunk but are still able to use improvements from other repos that have been rejected by the community. There are licensing issues that I would have to deal with as a maintainer of a private repo if I start to include work from non-Apache repos since I can not be quite so sure that the contributions to the private repo have been released to me under an Apache license. I am not advocating a shift to git, just trying to support Jacopo's suggestion of looking at workflow first with a slight addition of extending the discussion to project management philosophy since that seems to be a key motivation underlying the suggestion to move. Ron -- Ron Wheeler President Artifact Software Inc email: rwhee...@artifact-software.com skype: ronaldmwheeler phone: 866-970-2435, ext 102
[jira] [Commented] (OFBIZ-6085) Add support for production run inventory tracking
[ https://issues.apache.org/jira/browse/OFBIZ-6085?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14505138#comment-14505138 ] Christian Carlow commented on OFBIZ-6085: - None of those components supported associations down to relations(TimeEntryAssoc) between the individual party units-of-work which is what is needed for inspection functionality on my end. More than one worker can declare produced at any task so there is a need to relate declarations together to deduce adequate production inspection reports. Even if entities currently supported the needed functionality entering the data would be a much more cumbersome process compared to what the patch offers. It seems if inspections are really covered in OFBiz then there would at least exist a routing task workEffortPurposeType for inspection as there are for manufacturing, assembling, and sub-contracting which the patch adds. Would it be better if every little change were extracted from the patch and created as separate issues such as the one-liner to add the inspection workEffortPurposeType on which the overall issue is dependent? Add support for production run inventory tracking - Key: OFBIZ-6085 URL: https://issues.apache.org/jira/browse/OFBIZ-6085 Project: OFBiz Issue Type: Improvement Components: manufacturing Affects Versions: Trunk Reporter: Christian Carlow Assignee: Pierre Smits Attachments: OFBIZ-6085.patch Production run inventory tracking seems worthy of support so that production managers can get an idea of the department work load. InventoryItemDetails should be created during production run declarations so that the material that was stocked out for the production run can be tracked while it is being manufacturing into the good. Essentially is would be like stock moves or inventory xfers occuring within the production runs for the task fixed asset facilities/locations. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-6085) Add support for production run inventory tracking
[ https://issues.apache.org/jira/browse/OFBIZ-6085?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14505169#comment-14505169 ] Christian Carlow commented on OFBIZ-6085: - Pierre, An inventory transfer approval process was not accounted for in the patch. It was simply creates a product transfer based on the functionality provided in OFBIZ-6042 with status IXF_COMPLETE. Perhaps the status should be available as option to support approvals. I'll also work on default options that prevent time entries by default but having the feature available OOTB would be convenient. Add support for production run inventory tracking - Key: OFBIZ-6085 URL: https://issues.apache.org/jira/browse/OFBIZ-6085 Project: OFBiz Issue Type: Improvement Components: manufacturing Affects Versions: Trunk Reporter: Christian Carlow Assignee: Pierre Smits Attachments: OFBIZ-6085.patch Production run inventory tracking seems worthy of support so that production managers can get an idea of the department work load. InventoryItemDetails should be created during production run declarations so that the material that was stocked out for the production run can be tracked while it is being manufacturing into the good. Essentially is would be like stock moves or inventory xfers occuring within the production runs for the task fixed asset facilities/locations. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: move to git.
I am not sure that this should come as a surprise or a real difference in the current state. It is possible for anyone to fork the project. With git it could be easier to contribute back changes from this fork. Of course, the code bases could diverge to a point where sharing updates becomes too complex for both sides. The real issue is whether there is sufficient dissatisfaction with the current workflow and product direction for another community of like-minded committers to build to a size capable of managing a better fork. Ron On 21/04/2015 2:21 AM, Pierre Smits wrote: Quoting: We are also prepared to be assertive regarding this situation. If the project does not move to GIT then Brainfood is willing to participate in a consortium of organizations that will peer with each other to share updates to the master branch for their local OFBiz repository. Such an arrangement will, effectively, result in a distributed master repository image. Thanks Ean for the position of *Brainfood* in this position. It comes across as 'Do it our way, or else'. You are free to make such statements and when followed through there will be consequences. For all participating in this project. One I can see standing out clearly is: no more participation in/contribution from the employees of Brainfood and from the other companies in that consortium back into the project. If that is going to happen, I will say: 'I thank you for all the contributions you did to the project'. And I will check in my sentiments at the door. I do hope that if you do you also resign totally from this project. I rather have the community comes to its decision based on sound/valid arguments, not (veiled) threats. Best regards, Pierre Smits *ORRTIZ.COM http://www.orrtiz.com* Services Solutions for Cloud- Based Manufacturing, Professional Services and Retail Trade http://www.orrtiz.com On Tue, Apr 21, 2015 at 2:08 AM, Ean Schuessler e...@brainfood.com wrote: - Original Message - From: Jacques Le Roux jacques.le.r...@les7arts.com Subject: Re: move to git. Like Adrian and mostly for the same reasons, I don't believe we need Git. But there is one other major reason which has already been discussed in the other common ASF MLs. As Taher exulted, it's possible to create local branches. So people are able to do a lot of work alone without exchanging before committing or submitting. It will certainly not help to have this possibility. I disagree. It is useful in many situations for OFBiz developers to create a local repository that is not globally shared. Some customers may even require such a situation for security or legal reasons. Remember our recent discussion on the lack or core commits reviews. With Git you end with commits bursts or big patches and it's then hard to review and too late to share ideas. So unlike Adrian, I'm even strongly against it. I will not hesitate to use a -1 if necessary! We are also prepared to be assertive regarding this situation. If the project does not move to GIT then Brainfood is willing to participate in a consortium of organizations that will peer with each other to share updates to the master branch for their local OFBiz repository. Such an arrangement will, effectively, result in a distributed master repository image. If anyone else is interested in such an arrangement please feel free to speak up and we can begin the planning process. -- Ron Wheeler President Artifact Software Inc email: rwhee...@artifact-software.com skype: ronaldmwheeler phone: 866-970-2435, ext 102
Re: Long: Re: discussion: Move to Maven was:Re: svn commit: r1674216 - in /ofbiz/trunk: framework/start/pom.xml pom.xml
On 04/21/2015 04:06 PM, Nicolas Malin wrote: Le 21/04/2015 22:37, Adam Heath a écrit : My commit is not breaking anything. Why remove something that is harmless? Let's be positive and forward enabling; if a commit is reverted, then that reversion has not stopped any discussion, and now the original committer will have to do more work to re-add what was removed. Definitely, all commiter try to have a positive attitude to improve OFBiz. Your commit break nothing (on technical aspect), and I'm sure maven would be a good improvement. Only, Jacopo start a discussion to improve OFBiz with Gradle http://ofbiz.135035.n4.nabble.com/Discussion-migrating-from-Ant-to-Gradle-td4654092.html#a4654170 and adding pom.xml has an effect of bombshell. If you explain before on this thread that maven is better and why, your commit would be appreciate in its just value. Before your commit I had not idea on gradle or maven, but with my french mentality now I prefer Gradle ;) (completely not subjective!) Gradle is a non-starter. When I saw that mentioned, I actually did do some comparisons. In google, search for maven, then gradle. See how many responses each one gets. Then, go to trends.google.com, compare the above 2 items, and then add ant. You might want to say apache ant or apache maven, and/or add java terms. Then, also do a A vs B vs C search, aka, maven vs gradle vs ant. After doing this, maven is still the right choice.
Re: move to git.
Le 21/04/2015 17:53, Hans Bakker a écrit : It also shows that programmers like to change the world of the end-users, however forget to improve themselves the way they work Are you insinuating that I'm fossilised and against changes in order to improve the way I work? If so you are wrong! Jacques PS: I will be totally off for 3 days for personal reasons, so don't expect more posts from me before Sunday evening... Have fun...
Re: Long: Re: discussion: Move to Maven was:Re: svn commit: r1674216 - in /ofbiz/trunk: framework/start/pom.xml pom.xml
Le 21/04/2015 22:37, Adam Heath a écrit : My commit is not breaking anything. Why remove something that is harmless? Let's be positive and forward enabling; if a commit is reverted, then that reversion has not stopped any discussion, and now the original committer will have to do more work to re-add what was removed. Definitely, all commiter try to have a positive attitude to improve OFBiz. Your commit break nothing (on technical aspect), and I'm sure maven would be a good improvement. Only, Jacopo start a discussion to improve OFBiz with Gradle http://ofbiz.135035.n4.nabble.com/Discussion-migrating-from-Ant-to-Gradle-td4654092.html#a4654170 and adding pom.xml has an effect of bombshell. If you explain before on this thread that maven is better and why, your commit would be appreciate in its just value. Before your commit I had not idea on gradle or maven, but with my french mentality now I prefer Gradle ;) (completely not subjective!) You are a competent commiter but please community over the code. Regards Nicolas
Re: Long: Re: discussion: Move to Maven was:Re: svn commit: r1674216 - in /ofbiz/trunk: framework/start/pom.xml pom.xml
On 04/21/2015 04:30 PM, Jacques Le Roux wrote: Le 21/04/2015 23:17, Adam Heath a écrit : On 04/21/2015 04:06 PM, Nicolas Malin wrote: Le 21/04/2015 22:37, Adam Heath a écrit : My commit is not breaking anything. Why remove something that is harmless? Let's be positive and forward enabling; if a commit is reverted, then that reversion has not stopped any discussion, and now the original committer will have to do more work to re-add what was removed. Definitely, all commiter try to have a positive attitude to improve OFBiz. Your commit break nothing (on technical aspect), and I'm sure maven would be a good improvement. Only, Jacopo start a discussion to improve OFBiz with Gradle http://ofbiz.135035.n4.nabble.com/Discussion-migrating-from-Ant-to-Gradle-td4654092.html#a4654170 and adding pom.xml has an effect of bombshell. If you explain before on this thread that maven is better and why, your commit would be appreciate in its just value. Before your commit I had not idea on gradle or maven, but with my french mentality now I prefer Gradle ;) (completely not subjective!) Gradle is a non-starter. When I saw that mentioned, I actually did do some comparisons. In google, search for maven, then gradle. See how many responses each one gets. Then, go to trends.google.com, compare the above 2 items, and then add ant. You might want to say apache ant or apache maven, and/or add java terms. Then, also do a A vs B vs C search, aka, maven vs gradle vs ant. After doing this, maven is still the right choice. Quantity is not quality That seems to be a bit of an abrupt statement. Do you have anything more substantive to say? Did you actually attempt to dig down into the suggestions I gave? Or was this a knee-jerk response to my attempt at actually investigating gradle?
Long: Re: discussion: Move to Maven was:Re: svn commit: r1674216 - in /ofbiz/trunk: framework/start/pom.xml pom.xml
On 04/21/2015 12:29 AM, Jacopo Cappellato wrote: On Apr 21, 2015, at 12:33 AM, Adam Heath doo...@brainfood.com wrote: (picking a random email to respond to; I haven't read anything of this thread all weekend, I will need to spend some time doing so) Fyi, I have framework/start, base, and entity all compiling with maven now. API test cases work. Separate foo.jar and foo-test.jar are done. META-INF/services/ all located properly. Everything in base/lib/** and entity/lib/** has dependency settings in pom.xml, but *without* having to download anything(yet). I can't stress enough that there are *no* changes to any existing files. Absolutely none. As such, due to the volume of this discussion, I will be coming up with a way to have all these poms overlayed(or some other technical solution) to an unmodified ofbiz checkout. Git submodules might not be the right approach, I need to look at git subtree a bit more. ps: It's suprising how quickly I was able to start getting maven to work. I thought it would be extremely difficult. pps: I did a comparison of ant, ivy, maven, and gradle at http://trends.google.com/. Maven is the correct choice, gradle is too new. Hi Adam, I would suggest you to revert your commit until this discussion settles down and a final decision is taken by the community. My commit is not breaking anything. Why remove something that is harmless? Let's be positive and forward enabling; if a commit is reverted, then that reversion has not stopped any discussion, and now the original committer will have to do more work to re-add what was removed. This particular commit has not changed anyone's workflow, has not altered any existing file; it hasn't even broken any automated tests. Has anyone complained about eclipse or netbeans ceasing to function, because suddenly there is a pom.xml at the top level? in fact, no one will notice unless they run maven themselves. Seriously, what is the harm in leaving this early POC in trunk, esp. when I am willing to move over to an svn branch away from trunk? You have my attention. I have altered my off-work hours, to give up some of my free time, to improve the project. That is a big deal for me. Why not make use of this time in a productive matter? I am willing to do work. I am willing to move forward. I am implementing. Also, and this may sound like I'm tooting my own horn(well, ok, it is), but *I* implemented macros.xml and common.xml. I made the build system simpler. We used to have to copy the full build.xml into every component, and any changes had to be done to all of them. With this new build system(stating again, nothing has been broken *at all* with what has been added), not only will we be able to have the same set of current features, but we will get *even more*. Proper inter-project dependencies. Proper downloading of external libraries. No longer will anything be embedded. The LICENSE and NOTICE files will be reduced to a fraction of their size(and auto-generated, there's a maven plugin for this, based on all listed dependency items). All those project pages you see about project info, javadocs, etc, are produced by maven plugins. Better project distribution(maven can publish directory to a repo). Automatic version updates(all that TRUNK stuff in my examples). OFBiz will be a better behaved system in the Apache Family. Less work will be needed to maintain our own custom build.xml, as now the community at large will continue to improve the maven ecosystem. Less NIH. ps: In case you didn't notice, I have created a JIRA issue for this(OFBIZ-6271), and an svn branch. I will not be submitting separate patches into that issue; instead, changes will be in the branch. This allows for proper history to be maintained, once the change is merged in. I will continue to use git locally for this(as I always have), and will go silent for a short bit, but then mass-commit changes afterI have finessed them into something presentable. A new burst is coming in a few hours.
Re: Long: Re: discussion: Move to Maven was:Re: svn commit: r1674216 - in /ofbiz/trunk: framework/start/pom.xml pom.xml
Step forward to use Maven ! Easy to use. Difficult to learn. Eric Olagos bvba Heidi Dehaes Kerkstraat 34 2570 Duffel Belgium Tel. : 015/31 53 04 GSM :0485/22 35 80 E-mail : info.ola...@gmail.com http://www.olagos.eu http://www.olagos.com http://www.olagos.be http://www.olagos.nl 2015-04-21 22:37 GMT+02:00 Adam Heath doo...@brainfood.com: On 04/21/2015 12:29 AM, Jacopo Cappellato wrote: On Apr 21, 2015, at 12:33 AM, Adam Heath doo...@brainfood.com wrote: (picking a random email to respond to; I haven't read anything of this thread all weekend, I will need to spend some time doing so) Fyi, I have framework/start, base, and entity all compiling with maven now. API test cases work. Separate foo.jar and foo-test.jar are done. META-INF/services/ all located properly. Everything in base/lib/** and entity/lib/** has dependency settings in pom.xml, but *without* having to download anything(yet). I can't stress enough that there are *no* changes to any existing files. Absolutely none. As such, due to the volume of this discussion, I will be coming up with a way to have all these poms overlayed(or some other technical solution) to an unmodified ofbiz checkout. Git submodules might not be the right approach, I need to look at git subtree a bit more. ps: It's suprising how quickly I was able to start getting maven to work. I thought it would be extremely difficult. pps: I did a comparison of ant, ivy, maven, and gradle at http://trends.google.com/. Maven is the correct choice, gradle is too new. Hi Adam, I would suggest you to revert your commit until this discussion settles down and a final decision is taken by the community. My commit is not breaking anything. Why remove something that is harmless? Let's be positive and forward enabling; if a commit is reverted, then that reversion has not stopped any discussion, and now the original committer will have to do more work to re-add what was removed. This particular commit has not changed anyone's workflow, has not altered any existing file; it hasn't even broken any automated tests. Has anyone complained about eclipse or netbeans ceasing to function, because suddenly there is a pom.xml at the top level? in fact, no one will notice unless they run maven themselves. Seriously, what is the harm in leaving this early POC in trunk, esp. when I am willing to move over to an svn branch away from trunk? You have my attention. I have altered my off-work hours, to give up some of my free time, to improve the project. That is a big deal for me. Why not make use of this time in a productive matter? I am willing to do work. I am willing to move forward. I am implementing. Also, and this may sound like I'm tooting my own horn(well, ok, it is), but *I* implemented macros.xml and common.xml. I made the build system simpler. We used to have to copy the full build.xml into every component, and any changes had to be done to all of them. With this new build system(stating again, nothing has been broken *at all* with what has been added), not only will we be able to have the same set of current features, but we will get *even more*. Proper inter-project dependencies. Proper downloading of external libraries. No longer will anything be embedded. The LICENSE and NOTICE files will be reduced to a fraction of their size(and auto-generated, there's a maven plugin for this, based on all listed dependency items). All those project pages you see about project info, javadocs, etc, are produced by maven plugins. Better project distribution(maven can publish directory to a repo). Automatic version updates(all that TRUNK stuff in my examples). OFBiz will be a better behaved system in the Apache Family. Less work will be needed to maintain our own custom build.xml, as now the community at large will continue to improve the maven ecosystem. Less NIH. ps: In case you didn't notice, I have created a JIRA issue for this(OFBIZ-6271), and an svn branch. I will not be submitting separate patches into that issue; instead, changes will be in the branch. This allows for proper history to be maintained, once the change is merged in. I will continue to use git locally for this(as I always have), and will go silent for a short bit, but then mass-commit changes afterI have finessed them into something presentable. A new burst is coming in a few hours.
Re: Long: Re: discussion: Move to Maven was:Re: svn commit: r1674216 - in /ofbiz/trunk: framework/start/pom.xml pom.xml
Le 21/04/2015 23:17, Adam Heath a écrit : On 04/21/2015 04:06 PM, Nicolas Malin wrote: Le 21/04/2015 22:37, Adam Heath a écrit : My commit is not breaking anything. Why remove something that is harmless? Let's be positive and forward enabling; if a commit is reverted, then that reversion has not stopped any discussion, and now the original committer will have to do more work to re-add what was removed. Definitely, all commiter try to have a positive attitude to improve OFBiz. Your commit break nothing (on technical aspect), and I'm sure maven would be a good improvement. Only, Jacopo start a discussion to improve OFBiz with Gradle http://ofbiz.135035.n4.nabble.com/Discussion-migrating-from-Ant-to-Gradle-td4654092.html#a4654170 and adding pom.xml has an effect of bombshell. If you explain before on this thread that maven is better and why, your commit would be appreciate in its just value. Before your commit I had not idea on gradle or maven, but with my french mentality now I prefer Gradle ;) (completely not subjective!) Gradle is a non-starter. When I saw that mentioned, I actually did do some comparisons. In google, search for maven, then gradle. See how many responses each one gets. Then, go to trends.google.com, compare the above 2 items, and then add ant. You might want to say apache ant or apache maven, and/or add java terms. Then, also do a A vs B vs C search, aka, maven vs gradle vs ant. After doing this, maven is still the right choice. Quantity is not quality Jacques
Re: Long: Re: discussion: Move to Maven was:Re: svn commit: r1674216 - in /ofbiz/trunk: framework/start/pom.xml pom.xml
On 04/21/2015 04:07 PM, Heidi Dehaes wrote: Step forward to use Maven ! Easy to use. Difficult to learn. If you had asked me a week ago, at the start of ApacheCon, whether I thought a move to maven was possible, I would have gone postal; No way, hell no, not going to happen. By the end of day Thursday, I had a working PoC. And, I was returning from ApacheCon on Thursday, and didn't get home until 6pm or so. And this PoC was only 45 minutes of time investment. So, difficult to learn? No, not really.
Re: move to git.
On 04/21/2015 08:09 AM, Gil portenseigne wrote: In every case, contribution will have to be given within Jira to get into the project. This is not the case even today. I see changes in the svn log that have no jira issue.
Re: Long: Re: discussion: Move to Maven was:Re: svn commit: r1674216 - in /ofbiz/trunk: framework/start/pom.xml pom.xml
The discussion whether or not to switch is still ongoing, is still undecided. You have made your choice. That is your prerogative. No one within this community can deny you that. But you're forcing... Your preference without consensus within/of the Community. You're actions don't match the responsibilities that come with the privileges. Not those of a committer. Even less those of a PMC Member. Best regards, Pierre Smits *ORRTIZ.COM http://www.orrtiz.com* Services Solutions for Cloud- Based Manufacturing, Professional Services and Retail Trade http://www.orrtiz.com On Tue, Apr 21, 2015 at 11:17 PM, Adam Heath doo...@brainfood.com wrote: On 04/21/2015 04:06 PM, Nicolas Malin wrote: Le 21/04/2015 22:37, Adam Heath a écrit : My commit is not breaking anything. Why remove something that is harmless? Let's be positive and forward enabling; if a commit is reverted, then that reversion has not stopped any discussion, and now the original committer will have to do more work to re-add what was removed. Definitely, all commiter try to have a positive attitude to improve OFBiz. Your commit break nothing (on technical aspect), and I'm sure maven would be a good improvement. Only, Jacopo start a discussion to improve OFBiz with Gradle http://ofbiz.135035.n4.nabble.com/Discussion-migrating-from-Ant-to-Gradle-td4654092.html#a4654170 and adding pom.xml has an effect of bombshell. If you explain before on this thread that maven is better and why, your commit would be appreciate in its just value. Before your commit I had not idea on gradle or maven, but with my french mentality now I prefer Gradle ;) (completely not subjective!) Gradle is a non-starter. When I saw that mentioned, I actually did do some comparisons. In google, search for maven, then gradle. See how many responses each one gets. Then, go to trends.google.com, compare the above 2 items, and then add ant. You might want to say apache ant or apache maven, and/or add java terms. Then, also do a A vs B vs C search, aka, maven vs gradle vs ant. After doing this, maven is still the right choice.
Re: Long: Re: discussion: Move to Maven was:Re: svn commit: r1674216 - in /ofbiz/trunk: framework/start/pom.xml pom.xml
The nice thing about Maven is that very few people actually have to learn it. Once you have the pom set up and the projects structured, the maintenance is very simple and you don't really need to know Maven to do most common operations (update dependency version - change a property in the pom, add a new dependency - add a GAV). You are right for those who want to restructure the project or change the deliverable structure but you have the same problem with Ant. From the core committers' (project managers/gatekeeper) points of view, it is easier to see what libraries are being used and easy to know if someone tries to change one. I found it very easy to add junior programmers to our project since they did not have to learn the build system at all except for being able to click on the POM and select install. If there are a few Maven experts in the project, that should be sufficient. Ron On 21/04/2015 5:07 PM, Heidi Dehaes wrote: Step forward to use Maven ! Easy to use. Difficult to learn. Eric Olagos bvba Heidi Dehaes Kerkstraat 34 2570 Duffel Belgium Tel. : 015/31 53 04 GSM :0485/22 35 80 E-mail : info.ola...@gmail.com http://www.olagos.eu http://www.olagos.com http://www.olagos.be http://www.olagos.nl 2015-04-21 22:37 GMT+02:00 Adam Heath doo...@brainfood.com: On 04/21/2015 12:29 AM, Jacopo Cappellato wrote: On Apr 21, 2015, at 12:33 AM, Adam Heath doo...@brainfood.com wrote: (picking a random email to respond to; I haven't read anything of this thread all weekend, I will need to spend some time doing so) Fyi, I have framework/start, base, and entity all compiling with maven now. API test cases work. Separate foo.jar and foo-test.jar are done. META-INF/services/ all located properly. Everything in base/lib/** and entity/lib/** has dependency settings in pom.xml, but *without* having to download anything(yet). I can't stress enough that there are *no* changes to any existing files. Absolutely none. As such, due to the volume of this discussion, I will be coming up with a way to have all these poms overlayed(or some other technical solution) to an unmodified ofbiz checkout. Git submodules might not be the right approach, I need to look at git subtree a bit more. ps: It's suprising how quickly I was able to start getting maven to work. I thought it would be extremely difficult. pps: I did a comparison of ant, ivy, maven, and gradle at http://trends.google.com/. Maven is the correct choice, gradle is too new. Hi Adam, I would suggest you to revert your commit until this discussion settles down and a final decision is taken by the community. My commit is not breaking anything. Why remove something that is harmless? Let's be positive and forward enabling; if a commit is reverted, then that reversion has not stopped any discussion, and now the original committer will have to do more work to re-add what was removed. This particular commit has not changed anyone's workflow, has not altered any existing file; it hasn't even broken any automated tests. Has anyone complained about eclipse or netbeans ceasing to function, because suddenly there is a pom.xml at the top level? in fact, no one will notice unless they run maven themselves. Seriously, what is the harm in leaving this early POC in trunk, esp. when I am willing to move over to an svn branch away from trunk? You have my attention. I have altered my off-work hours, to give up some of my free time, to improve the project. That is a big deal for me. Why not make use of this time in a productive matter? I am willing to do work. I am willing to move forward. I am implementing. Also, and this may sound like I'm tooting my own horn(well, ok, it is), but *I* implemented macros.xml and common.xml. I made the build system simpler. We used to have to copy the full build.xml into every component, and any changes had to be done to all of them. With this new build system(stating again, nothing has been broken *at all* with what has been added), not only will we be able to have the same set of current features, but we will get *even more*. Proper inter-project dependencies. Proper downloading of external libraries. No longer will anything be embedded. The LICENSE and NOTICE files will be reduced to a fraction of their size(and auto-generated, there's a maven plugin for this, based on all listed dependency items). All those project pages you see about project info, javadocs, etc, are produced by maven plugins. Better project distribution(maven can publish directory to a repo). Automatic version updates(all that TRUNK stuff in my examples). OFBiz will be a better behaved system in the Apache Family. Less work will be needed to maintain our own custom build.xml, as now the community at large will continue to improve the maven ecosystem. Less NIH. ps: In case you didn't notice, I have created a JIRA issue for this(OFBIZ-6271), and an svn branch. I will not be submitting separate patches into that issue;
[jira] [Updated] (OFBIZ-6257) Upload function does not work on Party Manager.
[ https://issues.apache.org/jira/browse/OFBIZ-6257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Supachai Chaima-ngua updated OFBIZ-6257: Description: The StreamingNotSupportedException class does not found in Apache Commons Compress 1.4.1. Can you upgrade Apache Commons Compress to latest version ? I have tested with Apache Commons Compress 1.9, the upload file function was working fine. Bug page: http://demo-trunk-ofbiz.apache.org/partymgr/control/viewprofile?partyId=admin was:The StreamingNotSupportedException class does not found in Apache Commons Compress 1.4.1. Can you upgrade Apache Commons Compress to latest version ? I have tested with Apache Commons Compress 1.9, the upload file function was working fine. Upload function does not work on Party Manager. --- Key: OFBIZ-6257 URL: https://issues.apache.org/jira/browse/OFBIZ-6257 Project: OFBiz Issue Type: Bug Components: party Affects Versions: Trunk Reporter: Supachai Chaima-ngua Priority: Minor Labels: upload Fix For: Trunk Attachments: OFBiz Party Manager View Party Profile.png The StreamingNotSupportedException class does not found in Apache Commons Compress 1.4.1. Can you upgrade Apache Commons Compress to latest version ? I have tested with Apache Commons Compress 1.9, the upload file function was working fine. Bug page: http://demo-trunk-ofbiz.apache.org/partymgr/control/viewprofile?partyId=admin -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OFBIZ-6272) We want to use ofbiz for inventory management. Suppliers are the owners of the inventoy item. We want to charge inventory cost per kilo and per day. Is it possible to do
Nuwan Koggalahewa created OFBIZ-6272: Summary: We want to use ofbiz for inventory management. Suppliers are the owners of the inventoy item. We want to charge inventory cost per kilo and per day. Is it possible to do with existing features in ofbiz Key: OFBIZ-6272 URL: https://issues.apache.org/jira/browse/OFBIZ-6272 Project: OFBiz Issue Type: Wish Reporter: Nuwan Koggalahewa -- 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=14506028#comment-14506028 ] Adam Heath commented on OFBIZ-6271: --- Well, I just committed a bunch to this branch. Feature summary: * Dependencies are being listed. This is a big plus! * Some things done directly inside ant are now external; namely, the building of META-INF/services. * There are some src/main/resources and src/test/resources added to the project; existing tooling(aka, build.xml) needs might break; if so, then this particular item might have to be revisited. * Any kind of javadoc targets have not been attempted; this is a WIP. * I had done an ofbiz run with start and base compiled by maven, but hadn't yet attempted with entity, geronimo, and catalina. It might work, I'll check that. * I'd like to split out ofbiz-parent:pom into ofbiz-component:pom; this would reside at the same level as ofbiz-parent, and would more closely reflect the macros.xml/common.xml split. It also would allow for other children to be included without having to inherit the same kind of build process. Also, here are some commands to get everyone started: == mvn clean mvn clean package -DskipTests == 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 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)
[jira] [Commented] (OFBIZ-6270) base/json/JSON has been removed, with no deprecation window
[ https://issues.apache.org/jira/browse/OFBIZ-6270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14506007#comment-14506007 ] Adam Heath commented on OFBIZ-6270: --- When an external developer compiles their code, there is no class at that point in the tree. Nothing to mention that a deprecation has taken place. With this file added back(and with further documentation, which needs to be added), such a warning message will be shown. The entity system has gone through this deprecation cycle for many of its methods. Plus, this isn't some minor change to the name of a method, nor the addition or removal of some method parameter. This class was completely removed. No attempt at all was made to provide support for outside vendors. And this new class really is super simple. ps: I didn't implement all ways of using the previously existing code; namely, the resolve() logic is no longer valid, there is no way(I think) to request any of the available json object types(where calling code doesn't care if a map, list, number, string, boolean is returned), or some of the other features that were supported. base/json/JSON has been removed, with no deprecation window --- Key: OFBIZ-6270 URL: https://issues.apache.org/jira/browse/OFBIZ-6270 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: Trunk, 12.04.04 Reporter: Adam Heath Assignee: Adam Heath Priority: Critical The antlr-based json parser(at org.ofbiz.base.json.JSON.cc) was removed last October(2014-10-27). However, no backwards-compatible class was left in place, with a proper @Deprecation tag applied. The proper approach should have been to leave the class in place, adding @Deprecation, and leaving the json-lib.jar in place. Then, after one successful release, removing the actual code. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: Long: Re: discussion: Move to Maven was:Re: svn commit: r1674216 - in /ofbiz/trunk: framework/start/pom.xml pom.xml
As another point, you keep responding with attacks, instead of discussing actual datapoints. I'm mentioning features, additions, whatever, but I see nothing constructive from your direction. Let's move back to a technical discussion, and can we have a stop of this vitriol? On 04/21/2015 05:12 PM, Adam Heath wrote: On 04/21/2015 04:27 PM, Pierre Smits wrote: The discussion whether or not to switch is still ongoing, is still undecided. You have made your choice. That is your prerogative. No one within this community can deny you that. But you're forcing... Your preference without consensus within/of the Community. You're actions don't match the responsibilities that come with the privileges. Not those of a committer. Even less those of a PMC Member. Bother. You're really burning bridges here. Seriously. This is a personal attack from you. Go read the code of conduct that Jacopo posted. NOW! ps: as a history lesson, look who added java 1.5 generics, enhanced for-loop, and other new features, to *ALL* of the framework. That was all done without any kind of automatic tool. I typed in *every* *single* *one* of those lines. Just to state again, *ALL* of framework. And realize what that means. pps: Also, I have since filed an issue, and will be further commiting into a branch; so, your personal attacks aren't holding water.
Re: Discussion: Replace framework by Moqui.
Le 21/04/2015 09:48, Nicolas Malin a écrit : Le 20/04/2015 22:27, Pierre Smits a écrit : @Nicolas: in the end it is code change. Does your point of view reflect a veto? If the code change and the backward compatibility is present, no worries. We are an enterprise automation software not just a framework. Many companies trust in this stability and it's the main reason that I love OFBiz. I think we are relatively smart to don't break it ;) If I don't need backward compatibility without making customer project directly with Moqui/mantle, why keep Apache OFBiz ? That's the main point, thanks Nicolas! Jacques Best regards, Pierre Smits *ORRTIZ.COM http://www.orrtiz.com* Services Solutions for Cloud- Based Manufacturing, Professional Services and Retail Trade http://www.orrtiz.com On Mon, Apr 20, 2015 at 10:23 PM, Nicolas Malin nicolas.ma...@nereide.fr wrote: We have to be aware that every project (proprietary or Open Source) somewhere in the lifespan faces the moment of breaking backwards compatibility of their products. Even today there are still some products whose owners had to walk that walk and survived But that is more about the trustworthiness of the owner/project. And even then it were hard walks Moqui is very attractive, at this time I think it will be embed in OFBiz framework and not replace it. Because it's important to have the backward compatibility (java interface, and xml model reader can be used to make sure it). It's the OFBiz strong ! My point of view is : no backward compatibility, no discussion :) Nicolas Best regards, Pierre Smits *ORRTIZ.COM http://www.orrtiz.com* Services Solutions for Cloud- Based Manufacturing, Professional Services and Retail Trade http://www.orrtiz.com On Mon, Apr 20, 2015 at 8:39 PM, David E. Jones d...@me.com wrote: On 19 Apr 2015, at 22:31, Hans Bakker mailingl...@antwebsystems.com wrote: Again, as discussed at the ApacheCon in Austin we should start setting up a plan how to best move the ERP application to the Moqui framework. Moqui should not be part of the Apache foundation however the ERP application should remain there. Not only will it improve development of the ERP system but also will establish a clean separation between application and frameworks and hopefully getting David Jones back into the project. Yes, I realize i open the pandora box :-) but we need to make some major decisions I'll write this general reply with my OFBiz hat on, not my Moqui one. For Moqui Framework being used by OFBiz would be fantastic. It would bring a lot of well needed use and attention to the project and get it to a level that would take much longer with the current pace of growth. The growth is increasing, but it's nothing like the early years of OFBiz when the marketplace was so different... at that time OFBiz was unique as there weren't many feature-rich open source ecommerce or ERP systems, especially not in Java! I still find it amazing that OFBiz took off as much as it did... I was 23 years old when I started it, and only had 2 years of full-time development work behind me, and only 1 year of that was on ecommerce and ERP systems. Andrew had more experience with custom ecommerce development, but mostly in Perl IIRC. Anyway, enough nostalgia, back to the present. Using Moqui Framework in OFBiz would involve some really significant changes. The Moqui API is much cleaner (and everything is available through the single ExecutionContext class), but much different from the scattered static classes of the OFBiz framework. It may be possible to refactor much of the code with some regex search/replace wizardry, but there is a LOT of code in OFBiz to change. The data model and to some extent service definitions would be easy. I have some FTL templates for transforming those that I'd be happy to share (they are in a private repo right now). I used these to create the little Moqui component that has the OFBiz data model from version 10.04 which I used with a client to run a sort of OFBiz/Moqui hybrid. On that note... if anyone wants to experiment with this that might be a good place to start: get the latest data model definitions in a Moqui component, deploy the Moqui WAR in the same servlet container as OFBiz (just drop it in an OFBiz component) and then run them in parallel accessing the same DB and play with migrating a few screens/etc. IMO the biggest questions/concerns should be: 1. the significant effort required to do the migration 2. the impact on current users and applications OFBiz would end up as a very different beast after such changes, there is no way around it. For example screen hierarchies, nesting, and URLs are handled totally different in Moqui. There are some very cool newer open source tools used in Moqui, and some cool features in Moqui that don't (yet) exist in OFBiz, and many of the more advanced and recent ones aren't mentioned here, but this is a basic list of fundamental differences
Re: move to git.
Le 21/04/2015 10:19, Taher Alkhateeb a écrit : Hi Jacques and all, I think that sharing more than anything is a reason why git has an advantage. The distributed system means that every developer is a repository and therefore you can have endless chains of code propagation up to a committer. Just imagine a scenario like the following - A team is composed of people working on a major task - Two of the members (A and B) have their own sub-teams - There is exchange of code between the sub-teams, the major team and the project committer. Furthermore, the sub-teams need to pull updated data from the main repository of the project. So you have two integrators at the sub-team level and one integrator at the top team level plus a project committer. Sometimes, I want to pull code from the sub-team. Sometimes I want to pull code from the _other_ team. Then maybe I want to _merge_ work from both teams and run all tests. Then I want to clean the commit log with git rebase to cleanup the history into major commits to submit to the project committer. Now the project owner does not know / trust me but he knows / trusts you. And you in turn trust me so you can accept my commits. I cannot imagine how to implement the above without a distributed source code management system. Furthermore, it's important to note that ofbiz is not a closed proprietary project with a sacred repository hidden in the vault of some company. You _need_ contributions from others and you need to make it very easy and accessible. You need to have the ability for people to form teams and sub-teams to support you and your project by collaborating with each other without needing a committer. This is one of the main reasons for the massive success of the Linux Kernel where each of Linus Torvald's lieutenants is a committer for a sub-system with his/her own people they trust and work closely with. Some of this stuff is briefly shown in here http://www.git-scm.com/about/distributed I hope what I wrote is resonating with you and you're willing to give this idea a chance OK, you kind of answered to my questions to Adam, I need to re-read carefully... Jacques Taher Alkhateeb On Tue, Apr 21, 2015 at 10:23 AM, Jacques Le Roux jacques.le.r...@les7arts.com wrote: Le 21/04/2015 02:08, Ean Schuessler a écrit : - Original Message - From: Jacques Le Roux jacques.le.r...@les7arts.com Subject: Re: move to git. Like Adrian and mostly for the same reasons, I don't believe we need Git. But there is one other major reason which has already been discussed in the other common ASF MLs. As Taher exulted, it's possible to create local branches. So people are able to do a lot of work alone without exchanging before committing or submitting. It will certainly not help to have this possibility. I disagree. It is useful in many situations for OFBiz developers to create a local repository that is not globally shared. What about https://github.com/apache/ofbiz ? Some customers may even require such a situation for security or legal reasons. People can do what they want with OFBiz code on their side, sharing with the community is something else (and often harder) Jacques Remember our recent discussion on the lack or core commits reviews. With Git you end with commits bursts or big patches and it's then hard to review and too late to share ideas. So unlike Adrian, I'm even strongly against it. I will not hesitate to use a -1 if necessary! We are also prepared to be assertive regarding this situation. If the project does not move to GIT then Brainfood is willing to participate in a consortium of organizations that will peer with each other to share updates to the master branch for their local OFBiz repository. Such an arrangement will, effectively, result in a distributed master repository image. If anyone else is interested in such an arrangement please feel free to speak up and we can begin the planning process.
Re: move to git.
Thanks for clarification Adrian, I did not think about the Release Manager role Jacques Le 21/04/2015 12:59, Adrian Crum a écrit : Everyone is missing the point I am trying to make. I said, ***IF*** Jacopo said something like... As the OFBiz RM, ***IF*** Jacopo said he couldn't use Subversion to manage the OFBiz project, then the need to switch to something else would be obvious. I hope that clarifies my true meaning. Adrian Crum Sandglass Software www.sandglass-software.com On 4/21/2015 11:55 AM, Jacopo Cappellato wrote: On Apr 21, 2015, at 11:23 AM, Jacques Le Roux jacques.le.r...@les7arts.com wrote: Switching the main repo to Git does not add anything to the project itself. As I said before, Subversion handles our simple needs just fine. If Jacopo said something like, Managing our releases is impossible with Subversion, we really need to switch to Git - then we wouldn't be having this discussion, it would just happen because the need for the switch is obvious. But Jacopo is not saying that, and we don't have a problem using Subversion to manage the project. I don't remember Jacopo proposed to move to Git, it was Hans, then Taher, Adam and Ean seconded. I guess Taher, AntWeb and Brainfood are using Git and they would like to see OFBiz using it as well. In fact I didn't express my opinion or preference. At Hotwax we use Git for all our projects and we are happy with it. But this doesn't mean that svn is bad or old or not a good tool for OFBiz. In fact, as I mentioned to Hans at ApacheCon, before discussing svn vs git as mere tools, it would be more interesting and useful to review/discuss the contribution/commit workflows that these tools can enable and see if there is a room for a better workflow for the project. Jacopo
[jira] [Commented] (OFBIZ-6268) Improve Start.java Component Loading
[
https://issues.apache.org/jira/browse/OFBIZ-6268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14504780#comment-14504780
]
Adrian Crum commented on OFBIZ-6268:
Btw, in the current trunk, if I disable the specialpurpose folder
{code}
component-loader xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:noNamespaceSchemaLocation=http://ofbiz.apache.org/dtds/component-loader.xsd;
load-components parent-directory=framework/
load-components parent-directory=themes/
load-components parent-directory=applications/
!--
load-components parent-directory=specialpurpose/
--
load-components parent-directory=hot-deploy/
/component-loader
{code}
the specialpurpose component class paths are loaded anyway.
Improve Start.java Component Loading
Key: OFBIZ-6268
URL: https://issues.apache.org/jira/browse/OFBIZ-6268
Project: OFBiz
Issue Type: Improvement
Components: framework
Affects Versions: Upcoming Branch
Reporter: Adrian Crum
Priority: Minor
Attachments: OFBIZ-6268.patch
The current code for loading components parses configuration files twice.
This issue is intended for review of code improvements.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Re: move to git.
On Apr 21, 2015, at 12:59 PM, Adrian Crum adrian.c...@sandglass-software.com wrote: Everyone is missing the point I am trying to make. I said, ***IF*** Jacopo said something like... As the OFBiz RM, ***IF*** Jacopo said he couldn't use Subversion to manage the OFBiz project, then the need to switch to something else would be obvious. I hope that clarifies my true meaning. Adrian Crum It was clear to me since your first message but I have replied to Jacques as I was starting to feel dragged (or, in the context of git, I should say pulled) into the mix :-) Jacopo
Re: move to git.
@Adrian: I didn't miss your point! Opted not to respond, as I saw nothing wrong with/in the assertion/point you posted. Best regards, Pierre Smits *ORRTIZ.COM http://www.orrtiz.com* Services Solutions for Cloud- Based Manufacturing, Professional Services and Retail Trade http://www.orrtiz.com On Tue, Apr 21, 2015 at 12:59 PM, Adrian Crum adrian.c...@sandglass-software.com wrote: Everyone is missing the point I am trying to make. I said, ***IF*** Jacopo said something like... As the OFBiz RM, ***IF*** Jacopo said he couldn't use Subversion to manage the OFBiz project, then the need to switch to something else would be obvious. I hope that clarifies my true meaning. Adrian Crum Sandglass Software www.sandglass-software.com On 4/21/2015 11:55 AM, Jacopo Cappellato wrote: On Apr 21, 2015, at 11:23 AM, Jacques Le Roux jacques.le.r...@les7arts.com wrote: Switching the main repo to Git does not add anything to the project itself. As I said before, Subversion handles our simple needs just fine. If Jacopo said something like, Managing our releases is impossible with Subversion, we really need to switch to Git - then we wouldn't be having this discussion, it would just happen because the need for the switch is obvious. But Jacopo is not saying that, and we don't have a problem using Subversion to manage the project. I don't remember Jacopo proposed to move to Git, it was Hans, then Taher, Adam and Ean seconded. I guess Taher, AntWeb and Brainfood are using Git and they would like to see OFBiz using it as well. In fact I didn't express my opinion or preference. At Hotwax we use Git for all our projects and we are happy with it. But this doesn't mean that svn is bad or old or not a good tool for OFBiz. In fact, as I mentioned to Hans at ApacheCon, before discussing svn vs git as mere tools, it would be more interesting and useful to review/discuss the contribution/commit workflows that these tools can enable and see if there is a room for a better workflow for the project. Jacopo
Re: Long: Re: discussion: Move to Maven was:Re: svn commit: r1674216 - in /ofbiz/trunk: framework/start/pom.xml pom.xml
Adam, Shall we let other committers, who favour the ANT+IVY approach also move forward and implement their stuff as well as it will surely not break anything as well? Shall we also let other committers, who favour the Groovy/Gradle approach also move forward and implement their solutions as well as it will surely not break anything? Is this the path you want to walk? Code over Community? Engage in commit wars, just to force your way? Please don't! Collaborating is easier than forcing. The latter harms the project more than the first. Best regards Pierre Smits *ORRTIZ.COM http://www.orrtiz.com* Services Solutions for Cloud- Based Manufacturing, Professional Services and Retail Trade http://www.orrtiz.com On Tue, Apr 21, 2015 at 10:37 PM, Adam Heath doo...@brainfood.com wrote: On 04/21/2015 12:29 AM, Jacopo Cappellato wrote: On Apr 21, 2015, at 12:33 AM, Adam Heath doo...@brainfood.com wrote: (picking a random email to respond to; I haven't read anything of this thread all weekend, I will need to spend some time doing so) Fyi, I have framework/start, base, and entity all compiling with maven now. API test cases work. Separate foo.jar and foo-test.jar are done. META-INF/services/ all located properly. Everything in base/lib/** and entity/lib/** has dependency settings in pom.xml, but *without* having to download anything(yet). I can't stress enough that there are *no* changes to any existing files. Absolutely none. As such, due to the volume of this discussion, I will be coming up with a way to have all these poms overlayed(or some other technical solution) to an unmodified ofbiz checkout. Git submodules might not be the right approach, I need to look at git subtree a bit more. ps: It's suprising how quickly I was able to start getting maven to work. I thought it would be extremely difficult. pps: I did a comparison of ant, ivy, maven, and gradle at http://trends.google.com/. Maven is the correct choice, gradle is too new. Hi Adam, I would suggest you to revert your commit until this discussion settles down and a final decision is taken by the community. My commit is not breaking anything. Why remove something that is harmless? Let's be positive and forward enabling; if a commit is reverted, then that reversion has not stopped any discussion, and now the original committer will have to do more work to re-add what was removed. This particular commit has not changed anyone's workflow, has not altered any existing file; it hasn't even broken any automated tests. Has anyone complained about eclipse or netbeans ceasing to function, because suddenly there is a pom.xml at the top level? in fact, no one will notice unless they run maven themselves. Seriously, what is the harm in leaving this early POC in trunk, esp. when I am willing to move over to an svn branch away from trunk? You have my attention. I have altered my off-work hours, to give up some of my free time, to improve the project. That is a big deal for me. Why not make use of this time in a productive matter? I am willing to do work. I am willing to move forward. I am implementing. Also, and this may sound like I'm tooting my own horn(well, ok, it is), but *I* implemented macros.xml and common.xml. I made the build system simpler. We used to have to copy the full build.xml into every component, and any changes had to be done to all of them. With this new build system(stating again, nothing has been broken *at all* with what has been added), not only will we be able to have the same set of current features, but we will get *even more*. Proper inter-project dependencies. Proper downloading of external libraries. No longer will anything be embedded. The LICENSE and NOTICE files will be reduced to a fraction of their size(and auto-generated, there's a maven plugin for this, based on all listed dependency items). All those project pages you see about project info, javadocs, etc, are produced by maven plugins. Better project distribution(maven can publish directory to a repo). Automatic version updates(all that TRUNK stuff in my examples). OFBiz will be a better behaved system in the Apache Family. Less work will be needed to maintain our own custom build.xml, as now the community at large will continue to improve the maven ecosystem. Less NIH. ps: In case you didn't notice, I have created a JIRA issue for this(OFBIZ-6271), and an svn branch. I will not be submitting separate patches into that issue; instead, changes will be in the branch. This allows for proper history to be maintained, once the change is merged in. I will continue to use git locally for this(as I always have), and will go silent for a short bit, but then mass-commit changes afterI have finessed them into something presentable. A new burst is coming in a few hours.
Re: Long: Re: discussion: Move to Maven was:Re: svn commit: r1674216 - in /ofbiz/trunk: framework/start/pom.xml pom.xml
On 04/21/2015 04:27 PM, Pierre Smits wrote: The discussion whether or not to switch is still ongoing, is still undecided. You have made your choice. That is your prerogative. No one within this community can deny you that. But you're forcing... Your preference without consensus within/of the Community. You're actions don't match the responsibilities that come with the privileges. Not those of a committer. Even less those of a PMC Member. Bother. You're really burning bridges here. Seriously. This is a personal attack from you. Go read the code of conduct that Jacopo posted. NOW! ps: as a history lesson, look who added java 1.5 generics, enhanced for-loop, and other new features, to *ALL* of the framework. That was all done without any kind of automatic tool. I typed in *every* *single* *one* of those lines. Just to state again, *ALL* of framework. And realize what that means. pps: Also, I have since filed an issue, and will be further commiting into a branch; so, your personal attacks aren't holding water.
[jira] [Commented] (OFBIZ-6267) Replace ProductionRun.fo with widgets
[ https://issues.apache.org/jira/browse/OFBIZ-6267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14505179#comment-14505179 ] Christian Carlow commented on OFBIZ-6267: - OFBIZ-6266 was incorporated in this patch by adding maxPosition to ModelForm.java so that it could be passed in to foFormMacroLibrary.ftl#renderFormatSingleWrapperOpen when creating table-column/. foFormMacroLibrary.ftl and foScreenMacroLibrary.ftl were also extended to include new styles to replicate the format of the original report. Replace ProductionRun.fo with widgets - Key: OFBIZ-6267 URL: https://issues.apache.org/jira/browse/OFBIZ-6267 Project: OFBiz Issue Type: Improvement Components: manufacturing Reporter: Christian Carlow Assignee: Nicolas Malin Attachments: OFBIZ-6267.patch -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (OFBIZ-6085) Add support for production run inventory tracking
[ https://issues.apache.org/jira/browse/OFBIZ-6085?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14505169#comment-14505169 ] Christian Carlow edited comment on OFBIZ-6085 at 4/21/15 4:20 PM: -- Pierre, An inventory transfer approval process was not accounted for in the patch. It simply creates a product transfer based on the functionality provided in OFBIZ-6042 with status IXF_COMPLETE. Perhaps the status should be available as option to support approvals. I'll also work on default options that prevent time entries by default but having the feature available OOTB would be convenient. was (Author: ofbizzer): Pierre, An inventory transfer approval process was not accounted for in the patch. It was simply creates a product transfer based on the functionality provided in OFBIZ-6042 with status IXF_COMPLETE. Perhaps the status should be available as option to support approvals. I'll also work on default options that prevent time entries by default but having the feature available OOTB would be convenient. Add support for production run inventory tracking - Key: OFBIZ-6085 URL: https://issues.apache.org/jira/browse/OFBIZ-6085 Project: OFBiz Issue Type: Improvement Components: manufacturing Affects Versions: Trunk Reporter: Christian Carlow Assignee: Pierre Smits Attachments: OFBIZ-6085.patch Production run inventory tracking seems worthy of support so that production managers can get an idea of the department work load. InventoryItemDetails should be created during production run declarations so that the material that was stocked out for the production run can be tracked while it is being manufacturing into the good. Essentially is would be like stock moves or inventory xfers occuring within the production runs for the task fixed asset facilities/locations. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
