Re: VOTE: Begin Replacing OFBiz Framework With Moqui
I totally agree :) Le 30/04/2015 08:13, Jacopo Cappellato a écrit : +1 to this proposal by David, especially if we will be inclined to listen to David's advices because he is the one who designed the architecture of OFBiz and created Moqui: David's experience, knowledge and, more generally, skills will be invaluable in this process Jacopo
Re: VOTE: Begin Replacing OFBiz Framework With Moqui
+0 Adrian Crum Sandglass Software www.sandglass-software.com On 4/26/2015 3:44 PM, Adrian Crum wrote: As was discussed last week, there is some interest in replacing some (or all) of OFBiz with Moqui (http://www.moqui.org/framework/index.html). To the scope reasonable, I propose that we begin by converting the following parts of the OFBiz framework with Moqui: Entity Engine Service Engine Security Other parts of the OFBiz framework could be converted as well, but I think this would be a good starting point, and if is successful, then more of OFBiz can be converted later. I believe we can create a thunk component to help solve compatibility problems, but that is a separate discussion. I only mention it here in case compatibility concerns might influence a vote.
Re: VOTE: Begin Replacing OFBiz Framework With Moqui
My point was about the suggestion that you might want to add it as a TLP in ASF but there were concerns about the amount of effort to start an ASF project. It was not about the current fact that Moqui is already a project. I feel more comfortable about using ASF artifacts in our own products than I do about other libraries but we do use a lot of non-ASF software as key technologies (Spring, MySQL are key non-ASF technologies for Artifact Software). There was also some concern about the license under which Moqui is released. Ron On 30/04/2015 1:48 AM, David E. Jones wrote: On 29 Apr 2015, at 08:01, Ron Wheeler rwhee...@artifact-software.com wrote: What is the reason not to absorb Moqui or a fork of Moqui into OFBiz if we decide to replace the existing framework with Moqui. Is there a reason to have Moqui as a separate Apache project? Seems like extra overhead for no advantage. Moqui is already a separate project. The OFBiz community could certainly create a fork of Moqui and change whatever is desired (though that shouldn’t be necessary), but Moqui Framework is already a separate project with its own ecosystem of business artifacts and applications. That won’t ever change, Moqui will always be a separate project. -David -- Ron Wheeler President Artifact Software Inc email: rwhee...@artifact-software.com skype: ronaldmwheeler phone: 866-970-2435, ext 102
Re: VOTE: Begin Replacing OFBiz Framework With Moqui
Le 30/04/2015 18:03, Adam Heath a écrit : On 04/30/2015 12:22 AM, Jacopo Cappellato wrote: On Apr 29, 2015, at 9:17 PM, Jacques Le Roux jacques.le.r...@les7arts.com wrote: avalon-framework(4.2.0 in ofbiz) is no longer available. avalon.apache.org is closed(!). This was introduce with http://svn.apache.org/viewvc?view=revisionrevision=746645 and is no longer used Avalon is a dependency for FOP. jdom in ofbiz is 1.1, but 2.0.6 is available. Only JDOMException is used in images related classes Several jars have dependencies on jdom: Freemarker, Rome, Ant Contrib, Xstreams Jacopo Neither of these should be required by ofbiz, but should be auto-installed by a dependency resolver. Maven brings that to the table. So far we were mostly worried by possible incompatibilities, I agree that should no longer prevent us. And as said Jacopo it's the (logical) recommended way by the ASF (costs efficiency!) Jacques
Re: VOTE: Begin Replacing OFBiz Framework With Moqui
On 30 Apr 2015, at 05:31, Ron Wheeler rwhee...@artifact-software.com wrote: My point was about the suggestion that you might want to add it as a TLP in ASF but there were concerns about the amount of effort to start an ASF project. For Moqui Framework as an ASF project my concern really isn’t about the effort required, it would be WAY easier than when OFBiz went through the incubator. My concerns are about the community management approach, the forced growth of the community to graduate from the incubator (leading to hurried and possibly bad decisions about who to include as committers and PMC members), the ASF trademark policy and it’s use to go beyond what the Apache 2 license requires using trademarks as another channel for legal threats, the infrastructure constraints, and so on. The main benefit to joining the ASF: branding. It is a HUGE taboo to even say such a thing (and in the incubator proposals they want an ack that this is NOT a reason for joining the ASF), but it is the reality. For OFBiz the main benefit we've seen over time, IMO, had nothing to do with the oversight or community structure or infra or anything legal, but just having the Apache name on the project to boost confidence in the software. The irony is that the ASF has no policies related to software quality, but this is the public perception, helped along by no shortage of public statements by many people involved with the ASF. Maybe it’s more acceptable to say the ASF community model leads to higher quality software, that’s the general mantra anyway, but compared to other models I haven’t found that to be especially true. The ASF approach has it’s place and it’s great for certain types of software, but IMO is too inflexible for greater innovation to happen which is why most ASF projects start outside the ASF and join the foundation after reaching a certain point of maturity, and mostly by companies wanting to grow a community around a piece of software to reduce maintenance and support costs. That isn’t a bad thing, such software tends to do very well long term! -David
Re: VOTE: Begin Replacing OFBiz Framework With Moqui
On 04/30/2015 12:22 AM, Jacopo Cappellato wrote: On Apr 29, 2015, at 9:17 PM, Jacques Le Roux jacques.le.r...@les7arts.com wrote: avalon-framework(4.2.0 in ofbiz) is no longer available. avalon.apache.org is closed(!). This was introduce with http://svn.apache.org/viewvc?view=revisionrevision=746645 and is no longer used Avalon is a dependency for FOP. jdom in ofbiz is 1.1, but 2.0.6 is available. Only JDOMException is used in images related classes Several jars have dependencies on jdom: Freemarker, Rome, Ant Contrib, Xstreams Jacopo Neither of these should be required by ofbiz, but should be auto-installed by a dependency resolver. Maven brings that to the table.
Re: VOTE: Begin Replacing OFBiz Framework With Moqui
On Apr 29, 2015, at 5:01 PM, Ron Wheeler rwhee...@artifact-software.com wrote: What is the reason not to absorb Moqui or a fork of Moqui into OFBiz if we decide to replace the existing framework with Moqui. It could be done but with some concerns: * incorporating an external codebase requires some paperwork, if not a formal incubation process * forking Moqui may not be beneficial for the Moqui project that is growing and gaining momentum now; it could add confusion and over time incompatibilities between the forks * for historical reasons it may not be a wise choice: within *this* community and with the same persons we have now, David was unable to convince people about his new ideas; these new ideas are now implemented in Moqui; do the OFBiz people clearly understand the differences now and recognize that David was right? or are we just trying to grab the Moqui code and change it in the way that some of us think is right? I would like to hear, form the core committers of OFBiz, more about what they know and think about Moqui, and what are their plans about the integration... we may discover that there is not a shared plan and everyone thinks differently Is there a reason to have Moqui as a separate Apache project? Seems like extra overhead for no advantage. This approach would indeed solve most of the issues I mentioned above (about the fork) but we have to consider the following: * the current OFBiz framework is a huge codebase that is an asset for the OFBiz project: as a community we have to protect this asset unless we are sure that an external solution (Moqui binaries) already provides what we need; but this is an important decision because after that OFBiz will depend on the Moqui community/project * ideally, we should have more connections between Moqui and OFBiz communities, apart from David; in this way it will be easier to exchange requirements, plans etc... but I am not sure, again for historical reasons, how many of us would be a good fit for the Moqui community The two options mentioned above are both viable but there are pros and cons that need to be carefully evaluated and understood by everyone in the community before taking a decision for the greater good of the project (OFBiz, but also Moqui). Jacopo
Re: VOTE: Begin Replacing OFBiz Framework With Moqui
On Apr 28, 2015, at 10:39 AM, David E. Jones d...@me.com wrote: +1 - with the clarification that to me begin replacing implies a PoC effort in a branch. I just saw this thread and need a little time to think over the best approach, but off the top of my head it would look something like: - add the moqui-framework-version.jar file and all dependent jars to a component directory under ofbiz/framework (these could go in the base or common components, but might be best separate for clarity); if needed update jars currently used in OFBiz where an older version is used (don't know if this is the case for any, mention for the sake of completeness) - add a Moqui runtime directory somewhere in the OFBiz directory tree (Moqui uses this for various things); this would contain the Moqui tools components (with the Tools and System apps) so we have a UI to look at Moqui internals, OFBiz data, etc - either in the Moqui runtime directory or as an OFBiz component add a webroot webapp; Moqui is designed to run in a single webapp, and I'd recommend this be separate from the existing OFBiz webapps for now; when this webapp loads it will init the Moqui ExecutionContextFactory, when it shuts down it will destroy it - because initializing Moqui when the webroot webapp starts may not be adequate, make sure the Moqui static init stuff is in place and working (in the Moqui.java class) - run my little templates to transform current OFBiz data model XML files into Moqui ones and put those in a Moqui component in the Moqui runtime directory This would be a basic PoC to get Moqui running inside OFBiz, and then we could start the real PoC of either a thunk layer as Adrian proposed, probably accessing the statically initialized Moqui ExecutionContextFactory since most OFBiz framework classes are statically initialized, or using the more dynamic initialization through the Moqui webroot webapp. ... I would be happy to participate in this effort... if nothing else should be an interesting technical diversion. -David -1 to Begin Replacing OFBiz Framework With Moqui: the decision is very important and cannot be done on such uncertain basis; an experimental branch/poc is required to better understand the best architecture (there are several options) and impact for the applications; after that a cleaner roadmap could be discussed and only at that point a vote could be called; the persons willing to work on this should be prepared to accept that the community may not decide to accept the switch because I doubt they will get a pre-approval +1 to this proposal by David, especially if we will be inclined to listen to David's advices because he is the one who designed the architecture of OFBiz and created Moqui: David's experience, knowledge and, more generally, skills will be invaluable in this process Jacopo
Re: VOTE: Begin Replacing OFBiz Framework With Moqui
Le 30/04/2015 07:42, David E. Jones a écrit : On 29 Apr 2015, at 00:41, Jacques Le Rouxjacques.le.r...@les7arts.com wrote: I was rather reluctant about this but after the PoC concept has been introduced by several persons and reading the last exchange between Adam and David (where David said with the clarification that to me begin replacing implies a PoC effort in a branch) I sort of changed my mind, unlike Nicolas I will not vote -1 but 0. Like him I don't like the idea of plugging Moqui jars in OFBiz. On the other hand I understand Moqui is open source and everybody has access once a Github account is created hence 0 and not -1. It's still not a +1 because this adds extra complexitiy (2 repos, 2 set of tools, how to communicate, etc.) I don't like much :/ Moqui Framework IS a separate project, more or less like any other JAR or set of JARs included in OFBiz. It would always be maintained separately. If you think of using Moqui as adding another repo, that’s strange… like saying that OFBiz is currently split across dozens of repositories, one for each other open source project used in OFBiz. Obviously, as always, there will be bugs to fix and improvements to suggest so we will have to create pull request, that's what I meant. BTW how this compares to our current OFBiz strategy with Jira and releases logs? Jacques
Re: VOTE: Begin Replacing OFBiz Framework With Moqui
I was rather reluctant about this but after the PoC concept has been introduced by several persons and reading the last exchange between Adam and David (where David said with the clarification that to me begin replacing implies a PoC effort in a branch) I sort of changed my mind, unlike Nicolas I will not vote -1 but 0. Like him I don't like the idea of plugging Moqui jars in OFBiz. On the other hand I understand Moqui is open source and everybody has access once a Github account is created hence 0 and not -1. It's still not a +1 because this adds extra complexitiy (2 repos, 2 set of tools, how to communicate, etc.) I don't like much :/ David mentioned There is a chance Moqui Framework could become a separate ASF project, though the name Apache Moqui is oddly contradictory I guess still using Git as preferred commit medium (but as said Jacopo with anyway Svn as ultimate repo at the ASF). David also said he would prefer the distributed and moderated approaches used in the Linux kernel more than the community approach mandated by the ASF. which I believe was David's main concern when he created Moqui. That's could seem contradictory with ASF policy but remember that each project can define its own policy. Personnaly I don't see a problem with that, I trust David not wanting to become a benevolent dictator, he many times always proved to simply want the best for the OFBiz project. Mixed with I would rather let people come along, express interest, and thoroughly prove merit before they take on such a role. I understand that a Moqui podling would be created without direct connection with OFBiz committers. It's certainly too early to get conclusions about having 2 separate projects working together (in ASF or not), but I can already see some concerns If we introduce Moqui in OFBiz we can't avoid to speak about the 2 diverging ways of doing things at the UI level. Though I have not used Moqui I believe it is more flexible for this aspect, but again this add complexity. I know we are speaking about that yet, just saying, because if the PoC works it's the next step. Sorry for the long and confusing post, it's hard to explain what I feel better. Jacques Le 26/04/2015 16:44, Adrian Crum a écrit : As was discussed last week, there is some interest in replacing some (or all) of OFBiz with Moqui (http://www.moqui.org/framework/index.html). To the scope reasonable, I propose that we begin by converting the following parts of the OFBiz framework with Moqui: Entity Engine Service Engine Security Other parts of the OFBiz framework could be converted as well, but I think this would be a good starting point, and if is successful, then more of OFBiz can be converted later. I believe we can create a thunk component to help solve compatibility problems, but that is a separate discussion. I only mention it here in case compatibility concerns might influence a vote.
Re: VOTE: Begin Replacing OFBiz Framework With Moqui
Apache LABS could be utilised for such. That way persons can work on it, without hindrance of the projects by-laws and policies and without crowded our repository with branches having a limited lifespan (such as PoCs normally are intended). See http://labs.apache.org/ 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 Wed, Apr 29, 2015 at 10:11 AM, Scott Gray scott.g...@hotwaxsystems.com wrote: -1 I think plenty of people are in favor of the concept (including me) but a vote on replacing framework (and I assume eventually rewriting all of the applications) is premature. Has anyone looked into was is involved? With the level of interest from the community I think a POC of some sort is the best first step before we can hope to make an informed decision. Regards Scott On 27 Apr 2015 02:45, Adrian Crum adrian.c...@sandglass-software.com wrote: As was discussed last week, there is some interest in replacing some (or all) of OFBiz with Moqui (http://www.moqui.org/framework/index.html). To the scope reasonable, I propose that we begin by converting the following parts of the OFBiz framework with Moqui: Entity Engine Service Engine Security Other parts of the OFBiz framework could be converted as well, but I think this would be a good starting point, and if is successful, then more of OFBiz can be converted later. I believe we can create a thunk component to help solve compatibility problems, but that is a separate discussion. I only mention it here in case compatibility concerns might influence a vote. -- Adrian Crum Sandglass Software www.sandglass-software.com
Re: VOTE: Begin Replacing OFBiz Framework With Moqui
Le 28/04/2015 16:42, Adam Heath a écrit : On 04/28/2015 03:39 AM, David E. Jones wrote: +1 - with the clarification that to me begin replacing implies a PoC effort in a branch. I just saw this thread and need a little time to think over the best approach, but off the top of my head it would look something like: - add the moqui-framework-version.jar file and all dependent jars to a component directory under ofbiz/framework (these could go in the base or common components, but might be best separate for clarity); if needed update jars currently used in OFBiz where an older version is used (don't know if this is the case for any, mention for the sake of completeness) There are 2 separate items in this bullet point. I'll talk about the second, updating jar versions. HAHAHAHAHAHAHA! I have discovered that ofbiz is using hc.apache.org(HttpClient), and commons-httpclient. The former is the newer, rewritten, rearchitected, replacement for the latter. hc.apache.org(HttpClient) was introduced with https://issues.apache.org/jira/browse/OFBIZ-3180. I also created https://issues.apache.org/jira/browse/OFBIZ-4430 Never got a chance to seriously work on it The rest of the versioned jars are just as bad. Which ones? Jacques - add a Moqui runtime directory somewhere in the OFBiz directory tree (Moqui uses this for various things); this would contain the Moqui tools components (with the Tools and System apps) so we have a UI to look at Moqui internals, OFBiz data, etc Do each of the separate moqui sub-tools need their own runtime folder? How difficult would it be to have $OFBIZ_HOME/runtime/$tool1, runtime/$tool2, etc? - either in the Moqui runtime directory or as an OFBiz component add a webroot webapp; Moqui is designed to run in a single webapp, and I'd recommend this be separate from the existing OFBiz webapps for now; when this webapp loads it will init the Moqui ExecutionContextFactory, when it shuts down it will destroy it Wait. The webapp initializes the context factory? There isn't a separate way to do this? Does that mean Moqui is tied to a webapp? What kind of webapp? I hope it isn't servlets. You mention it as weboot. Does that mean it runs at the root of the webserver? This might be a noob question. - because initializing Moqui when the webroot webapp starts may not be adequate, make sure the Moqui static init stuff is in place and working (in the Moqui.java class) Ah. So that means that means that moqui-component needs a container definition. Ignore the above then. I have never liked that ofbiz startup delays initialization of certain components until they are magically called from some random bit of java code, aka, the web container starting up. - run my little templates to transform current OFBiz data model XML files into Moqui ones and put those in a Moqui component in the Moqui runtime directory Sorry for the noob question, but does that mean that both ofbiz entityengine and moqui could talk to the same database backend(s), at the same time? This would be a basic PoC to get Moqui running inside OFBiz, and then we could start the real PoC of either a thunk layer as Adrian proposed, probably accessing the statically initialized Moqui ExecutionContextFactory since most OFBiz framework classes are statically initialized, or using the more dynamic initialization through the Moqui webroot webapp. Actually, a bit simpler, would be to just see if moqui can be added to the classpath, and loaded, before translating any datamodels. Once that is done, then have a method that translates the model definitions dynamically at load time, so that they are always kept in sync. Once this has proven, then that dynamic translation can be removed, and the output of it can become the new static definition of the model. The reason I suggest this way, is so that hot-deploy components(or other file modifications) that alter the entity definitions dynamically(extends-entity, whole new entity definitions) can also work transparently. For those who want a brief introduction to some of the differences between OFBiz Framework and Moqui Framework, see the OFBiz: How does it compare to Moqui? section at: http://www.moqui.org/framework/index.html That is an older document and isn't meant to be any sort of exhaustive list of the features of Moqui versus the features of OFBiz Framework, but gives a general idea about how some of the similar tools are different. For those who want to dive a bit deeper the Tutorial may be helpful: http://www.moqui.org/framework/docs/Tutorial.html For those who want to dive in neck deep the Making Apps with Moqui book is the more exhaustive reference to Moqui (though about 8 months old now and there are many new features, summarized in the ReleaseNotes.txt file for those curious): http://www.moqui.org/MakingAppsWithMoqui-1.0.pdf https://github.com/moqui/moqui/blob/master/ReleaseNotes.txt I would be happy to participate in
Re: VOTE: Begin Replacing OFBiz Framework With Moqui
-1 I think plenty of people are in favor of the concept (including me) but a vote on replacing framework (and I assume eventually rewriting all of the applications) is premature. Has anyone looked into was is involved? With the level of interest from the community I think a POC of some sort is the best first step before we can hope to make an informed decision. Regards Scott On 27 Apr 2015 02:45, Adrian Crum adrian.c...@sandglass-software.com wrote: As was discussed last week, there is some interest in replacing some (or all) of OFBiz with Moqui (http://www.moqui.org/framework/index.html). To the scope reasonable, I propose that we begin by converting the following parts of the OFBiz framework with Moqui: Entity Engine Service Engine Security Other parts of the OFBiz framework could be converted as well, but I think this would be a good starting point, and if is successful, then more of OFBiz can be converted later. I believe we can create a thunk component to help solve compatibility problems, but that is a separate discussion. I only mention it here in case compatibility concerns might influence a vote. -- Adrian Crum Sandglass Software www.sandglass-software.com
Re: VOTE: Begin Replacing OFBiz Framework With Moqui
I wonder what the impact will be on the apps currently available in 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 Wed, Apr 29, 2015 at 4:12 AM, Hans Bakker h.bak...@antwebsystems.com wrote: Hi David, very good to have you back in the project! Exiting times ahead! Regards, Hans On 28/04/15 15:39, David E. Jones wrote: +1 - with the clarification that to me begin replacing implies a PoC effort in a branch. I just saw this thread and need a little time to think over the best approach, but off the top of my head it would look something like: - add the moqui-framework-version.jar file and all dependent jars to a component directory under ofbiz/framework (these could go in the base or common components, but might be best separate for clarity); if needed update jars currently used in OFBiz where an older version is used (don't know if this is the case for any, mention for the sake of completeness) - add a Moqui runtime directory somewhere in the OFBiz directory tree (Moqui uses this for various things); this would contain the Moqui tools components (with the Tools and System apps) so we have a UI to look at Moqui internals, OFBiz data, etc - either in the Moqui runtime directory or as an OFBiz component add a webroot webapp; Moqui is designed to run in a single webapp, and I'd recommend this be separate from the existing OFBiz webapps for now; when this webapp loads it will init the Moqui ExecutionContextFactory, when it shuts down it will destroy it - because initializing Moqui when the webroot webapp starts may not be adequate, make sure the Moqui static init stuff is in place and working (in the Moqui.java class) - run my little templates to transform current OFBiz data model XML files into Moqui ones and put those in a Moqui component in the Moqui runtime directory This would be a basic PoC to get Moqui running inside OFBiz, and then we could start the real PoC of either a thunk layer as Adrian proposed, probably accessing the statically initialized Moqui ExecutionContextFactory since most OFBiz framework classes are statically initialized, or using the more dynamic initialization through the Moqui webroot webapp. For those who want a brief introduction to some of the differences between OFBiz Framework and Moqui Framework, see the OFBiz: How does it compare to Moqui? section at: http://www.moqui.org/framework/index.html That is an older document and isn't meant to be any sort of exhaustive list of the features of Moqui versus the features of OFBiz Framework, but gives a general idea about how some of the similar tools are different. For those who want to dive a bit deeper the Tutorial may be helpful: http://www.moqui.org/framework/docs/Tutorial.html For those who want to dive in neck deep the Making Apps with Moqui book is the more exhaustive reference to Moqui (though about 8 months old now and there are many new features, summarized in the ReleaseNotes.txt file for those curious): http://www.moqui.org/MakingAppsWithMoqui-1.0.pdf https://github.com/moqui/moqui/blob/master/ReleaseNotes.txt I would be happy to participate in this effort... if nothing else should be an interesting technical diversion. -David On 26 Apr 2015, at 07:44, Adrian Crum adrian.c...@sandglass-software.com wrote: As was discussed last week, there is some interest in replacing some (or all) of OFBiz with Moqui (http://www.moqui.org/framework/index.html). To the scope reasonable, I propose that we begin by converting the following parts of the OFBiz framework with Moqui: Entity Engine Service Engine Security Other parts of the OFBiz framework could be converted as well, but I think this would be a good starting point, and if is successful, then more of OFBiz can be converted later. I believe we can create a thunk component to help solve compatibility problems, but that is a separate discussion. I only mention it here in case compatibility concerns might influence a vote. -- Adrian Crum Sandglass Software www.sandglass-software.com
off-topic: Re: VOTE: Begin Replacing OFBiz Framework With Moqui
On 04/29/2015 02:17 PM, Jacques Le Roux wrote: [snip] Finally Maven proved to be useful :) [snip] Everything always has at least one use; physical things can be paper weights; virtual things can take up disk space. jk
Re: VOTE: Begin Replacing OFBiz Framework With Moqui
Le 29/04/2015 16:49, Adam Heath a écrit : On 04/29/2015 01:39 AM, Jacques Le Roux wrote: Le 28/04/2015 16:42, Adam Heath a écrit : On 04/28/2015 03:39 AM, David E. Jones wrote: +1 - with the clarification that to me begin replacing implies a PoC effort in a branch. I just saw this thread and need a little time to think over the best approach, but off the top of my head it would look something like: - add the moqui-framework-version.jar file and all dependent jars to a component directory under ofbiz/framework (these could go in the base or common components, but might be best separate for clarity); if needed update jars currently used in OFBiz where an older version is used (don't know if this is the case for any, mention for the sake of completeness) There are 2 separate items in this bullet point. I'll talk about the second, updating jar versions. HAHAHAHAHAHAHA! I have discovered that ofbiz is using hc.apache.org(HttpClient), and commons-httpclient. The former is the newer, rewritten, rearchitected, replacement for the latter. hc.apache.org(HttpClient) was introduced with https://issues.apache.org/jira/browse/OFBIZ-3180. I also created https://issues.apache.org/jira/browse/OFBIZ-4430 Never got a chance to seriously work on it The rest of the versioned jars are just as bad. Which ones? Jacques org.springframework seems to be at some 4.x version. Ofbiz has 3.1. birt is using date-based jars from 2010 and 2013. Yes: https://issues.apache.org/jira/browse/OFBIZ-5744 ant is at 1.9.4, we have 1.9.0. avalon-framework(4.2.0 in ofbiz) is no longer available. avalon.apache.org is closed(!). This was introduce with http://svn.apache.org/viewvc?view=revisionrevision=746645 and is no longer used jdom in ofbiz is 1.1, but 2.0.6 is available. Only JDOMException is used in images related classes junit is 4.10, but 4.12 is available. resolver in base is 2.9.1, resolver in birt is 1.2.0(with a date), but these may be different libs. serializer is base is 2.9.1, serializer in birt is 2.7.1(with a date). Yes Birt needs to be updated, Chatree who is now a committer said he will take care of it when he will have finished his studies (Master) httpunit was last release in May 2008; xpp3 was last released in November 2006. I could go on. This is based on reading the top-level pom.xml in OFBIZ-6271, then doing some quick google searches and finding the download pages. There are also many jars that have no version at all in their name. Thanks, we should use to create Jiras, all of them... Finally Maven proved to be useful :) But I remember some cases we needed to change our code because of changes in the libs. It was never hard stuff but still we had to get our hand dirty. Jacques PS: this remembers we should certainly look at updating jQuery also
Re: VOTE: Begin Replacing OFBiz Framework With Moqui
On 04/29/2015 01:39 AM, Jacques Le Roux wrote: Le 28/04/2015 16:42, Adam Heath a écrit : On 04/28/2015 03:39 AM, David E. Jones wrote: +1 - with the clarification that to me begin replacing implies a PoC effort in a branch. I just saw this thread and need a little time to think over the best approach, but off the top of my head it would look something like: - add the moqui-framework-version.jar file and all dependent jars to a component directory under ofbiz/framework (these could go in the base or common components, but might be best separate for clarity); if needed update jars currently used in OFBiz where an older version is used (don't know if this is the case for any, mention for the sake of completeness) There are 2 separate items in this bullet point. I'll talk about the second, updating jar versions. HAHAHAHAHAHAHA! I have discovered that ofbiz is using hc.apache.org(HttpClient), and commons-httpclient. The former is the newer, rewritten, rearchitected, replacement for the latter. hc.apache.org(HttpClient) was introduced with https://issues.apache.org/jira/browse/OFBIZ-3180. I also created https://issues.apache.org/jira/browse/OFBIZ-4430 Never got a chance to seriously work on it The rest of the versioned jars are just as bad. Which ones? Jacques org.springframework seems to be at some 4.x version. Ofbiz has 3.1. birt is using date-based jars from 2010 and 2013. ant is at 1.9.4, we have 1.9.0. avalon-framework(4.2.0 in ofbiz) is no longer available. avalon.apache.org is closed(!). jdom in ofbiz is 1.1, but 2.0.6 is available. junit is 4.10, but 4.12 is available. resolver in base is 2.9.1, resolver in birt is 1.2.0(with a date), but these may be different libs. serializer is base is 2.9.1, serializer in birt is 2.7.1(with a date). httpunit was last release in May 2008; xpp3 was last released in November 2006. I could go on. This is based on reading the top-level pom.xml in OFBIZ-6271, then doing some quick google searches and finding the download pages. There are also many jars that have no version at all in their name.
Re: VOTE: Begin Replacing OFBiz Framework With Moqui
On 29 Apr 2015, at 00:41, Jacques Le Roux jacques.le.r...@les7arts.com wrote: I was rather reluctant about this but after the PoC concept has been introduced by several persons and reading the last exchange between Adam and David (where David said with the clarification that to me begin replacing implies a PoC effort in a branch) I sort of changed my mind, unlike Nicolas I will not vote -1 but 0. Like him I don't like the idea of plugging Moqui jars in OFBiz. On the other hand I understand Moqui is open source and everybody has access once a Github account is created hence 0 and not -1. It's still not a +1 because this adds extra complexitiy (2 repos, 2 set of tools, how to communicate, etc.) I don't like much :/ Moqui Framework IS a separate project, more or less like any other JAR or set of JARs included in OFBiz. It would always be maintained separately. If you think of using Moqui as adding another repo, that’s strange… like saying that OFBiz is currently split across dozens of repositories, one for each other open source project used in OFBiz. Also keep in mind that there are other applications, both open source and commercial, based on Moqui. The ecosystem around Moqui and the applications around it are what have driven it to the point where it is now, and whether or not OFBiz uses Moqui all of that will continue. David mentioned There is a chance Moqui Framework could become a separate ASF project, though the name Apache Moqui is oddly contradictory I guess still using Git as preferred commit medium (but as said Jacopo with anyway Svn as ultimate repo at the ASF). David also said he would prefer the distributed and moderated approaches used in the Linux kernel more than the community approach mandated by the ASF. which I believe was David's main concern when he created Moqui. That's could seem contradictory with ASF policy but remember that each project can define its own policy. Personnaly I don't see a problem with that, I trust David not wanting to become a benevolent dictator, he many times always proved to simply want the best for the OFBiz project. Mixed with I would rather let people come along, express interest, and thoroughly prove merit before they take on such a role. I understand that a Moqui podling would be created without direct connection with OFBiz committers. It's certainly too early to get conclusions about having 2 separate projects working together (in ASF or not), but I can already see some concerns If we introduce Moqui in OFBiz we can't avoid to speak about the 2 diverging ways of doing things at the UI level. Though I have not used Moqui I believe it is more flexible for this aspect, but again this add complexity. I know we are speaking about that yet, just saying, because if the PoC works it's the next step. Sorry for the long and confusing post, it's hard to explain what I feel better. This is the crux of the discussion for OFBiz: how much of the development approach driven by the framework do you want to change? Do you want to continue doing things the same way or look at alternative approaches that might be better (cleaner application artifacts, easier customization, better security, a wider variety of tools, more efficient development)? You mentioned above the community structure as my main reason for creating Moqui… it is partly true in that it is the reason I chose to do it as a separate project and not an ASF project. However, the real reason was continuing to explore some of the principles that went into the design of the OFBiz Framework and taking them to the next level… including significant cleanups and modernization that the OFBiz Framework needs badly. My list of desired changes to OFBiz (after nearly a decade) got more and more into things that would have required dramatic refactoring and breaking backwards compatibility in MAJOR ways. After trying a bit within OFBiz it became obvious that was impossible, and would have been extremely inefficient in terms of the time required. Doing it as a separate project solved that. The real question behind this vote is: how do you want to do things in the future? If it is similar to how things are done in Moqui then it’s there for you to use. If you like the OFBiz framework tools as they are, then there’s no reason to even consider it. -David
Re: VOTE: Begin Replacing OFBiz Framework With Moqui
On 29 Apr 2015, at 08:01, Ron Wheeler rwhee...@artifact-software.com wrote: What is the reason not to absorb Moqui or a fork of Moqui into OFBiz if we decide to replace the existing framework with Moqui. Is there a reason to have Moqui as a separate Apache project? Seems like extra overhead for no advantage. Moqui is already a separate project. The OFBiz community could certainly create a fork of Moqui and change whatever is desired (though that shouldn’t be necessary), but Moqui Framework is already a separate project with its own ecosystem of business artifacts and applications. That won’t ever change, Moqui will always be a separate project. -David
Re: VOTE: Begin Replacing OFBiz Framework With Moqui
Thanks Jacopo, I was too fast, Jars dependencies hell :/ Jacques Le 30/04/2015 07:22, Jacopo Cappellato a écrit : On Apr 29, 2015, at 9:17 PM, Jacques Le Roux jacques.le.r...@les7arts.com wrote: avalon-framework(4.2.0 in ofbiz) is no longer available. avalon.apache.org is closed(!). This was introduce with http://svn.apache.org/viewvc?view=revisionrevision=746645 and is no longer used Avalon is a dependency for FOP. jdom in ofbiz is 1.1, but 2.0.6 is available. Only JDOMException is used in images related classes Several jars have dependencies on jdom: Freemarker, Rome, Ant Contrib, Xstreams Jacopo
Re: VOTE: Begin Replacing OFBiz Framework With Moqui
On Apr 29, 2015, at 9:17 PM, Jacques Le Roux jacques.le.r...@les7arts.com wrote: avalon-framework(4.2.0 in ofbiz) is no longer available. avalon.apache.org is closed(!). This was introduce with http://svn.apache.org/viewvc?view=revisionrevision=746645 and is no longer used Avalon is a dependency for FOP. jdom in ofbiz is 1.1, but 2.0.6 is available. Only JDOMException is used in images related classes Several jars have dependencies on jdom: Freemarker, Rome, Ant Contrib, Xstreams Jacopo
Re: VOTE: Begin Replacing OFBiz Framework With Moqui
What is the reason not to absorb Moqui or a fork of Moqui into OFBiz if we decide to replace the existing framework with Moqui. Is there a reason to have Moqui as a separate Apache project? Seems like extra overhead for no advantage. If Moqui is a separate deliverable of the OFBiz project and included in the OFBiz ERP as a clean dependency, then managing Moqui development with git, Maven and any other tool should not make the OFBiz universe unstable even if the main development stays on SVN and Ant. It should probably have its own release roadmap if it is used by other projects but once again, I don't see any negative impact on the rest of OFBiz. I am not sure that it is a good idea in general but these issues are not the source of any concern. Ron On 29/04/2015 3:41 AM, Jacques Le Roux wrote: I was rather reluctant about this but after the PoC concept has been introduced by several persons and reading the last exchange between Adam and David (where David said with the clarification that to me begin replacing implies a PoC effort in a branch) I sort of changed my mind, unlike Nicolas I will not vote -1 but 0. Like him I don't like the idea of plugging Moqui jars in OFBiz. On the other hand I understand Moqui is open source and everybody has access once a Github account is created hence 0 and not -1. It's still not a +1 because this adds extra complexitiy (2 repos, 2 set of tools, how to communicate, etc.) I don't like much :/ David mentioned There is a chance Moqui Framework could become a separate ASF project, though the name Apache Moqui is oddly contradictory I guess still using Git as preferred commit medium (but as said Jacopo with anyway Svn as ultimate repo at the ASF). David also said he would prefer the distributed and moderated approaches used in the Linux kernel more than the community approach mandated by the ASF. which I believe was David's main concern when he created Moqui. That's could seem contradictory with ASF policy but remember that each project can define its own policy. Personnaly I don't see a problem with that, I trust David not wanting to become a benevolent dictator, he many times always proved to simply want the best for the OFBiz project. Mixed with I would rather let people come along, express interest, and thoroughly prove merit before they take on such a role. I understand that a Moqui podling would be created without direct connection with OFBiz committers. It's certainly too early to get conclusions about having 2 separate projects working together (in ASF or not), but I can already see some concerns If we introduce Moqui in OFBiz we can't avoid to speak about the 2 diverging ways of doing things at the UI level. Though I have not used Moqui I believe it is more flexible for this aspect, but again this add complexity. I know we are speaking about that yet, just saying, because if the PoC works it's the next step. Sorry for the long and confusing post, it's hard to explain what I feel better. Jacques Le 26/04/2015 16:44, Adrian Crum a écrit : As was discussed last week, there is some interest in replacing some (or all) of OFBiz with Moqui (http://www.moqui.org/framework/index.html). To the scope reasonable, I propose that we begin by converting the following parts of the OFBiz framework with Moqui: Entity Engine Service Engine Security Other parts of the OFBiz framework could be converted as well, but I think this would be a good starting point, and if is successful, then more of OFBiz can be converted later. I believe we can create a thunk component to help solve compatibility problems, but that is a separate discussion. I only mention it here in case compatibility concerns might influence a vote. -- Ron Wheeler President Artifact Software Inc email: rwhee...@artifact-software.com skype: ronaldmwheeler phone: 866-970-2435, ext 102
Re: VOTE: Begin Replacing OFBiz Framework With Moqui
On 04/28/2015 03:39 AM, David E. Jones wrote: +1 - with the clarification that to me begin replacing implies a PoC effort in a branch. I just saw this thread and need a little time to think over the best approach, but off the top of my head it would look something like: - add the moqui-framework-version.jar file and all dependent jars to a component directory under ofbiz/framework (these could go in the base or common components, but might be best separate for clarity); if needed update jars currently used in OFBiz where an older version is used (don't know if this is the case for any, mention for the sake of completeness) There are 2 separate items in this bullet point. I'll talk about the second, updating jar versions. HAHAHAHAHAHAHA! I have discovered that ofbiz is using hc.apache.org(HttpClient), and commons-httpclient. The former is the newer, rewritten, rearchitected, replacement for the latter. The rest of the versioned jars are just as bad. - add a Moqui runtime directory somewhere in the OFBiz directory tree (Moqui uses this for various things); this would contain the Moqui tools components (with the Tools and System apps) so we have a UI to look at Moqui internals, OFBiz data, etc Do each of the separate moqui sub-tools need their own runtime folder? How difficult would it be to have $OFBIZ_HOME/runtime/$tool1, runtime/$tool2, etc? - either in the Moqui runtime directory or as an OFBiz component add a webroot webapp; Moqui is designed to run in a single webapp, and I'd recommend this be separate from the existing OFBiz webapps for now; when this webapp loads it will init the Moqui ExecutionContextFactory, when it shuts down it will destroy it Wait. The webapp initializes the context factory? There isn't a separate way to do this? Does that mean Moqui is tied to a webapp? What kind of webapp? I hope it isn't servlets. You mention it as weboot. Does that mean it runs at the root of the webserver? This might be a noob question. - because initializing Moqui when the webroot webapp starts may not be adequate, make sure the Moqui static init stuff is in place and working (in the Moqui.java class) Ah. So that means that means that moqui-component needs a container definition. Ignore the above then. I have never liked that ofbiz startup delays initialization of certain components until they are magically called from some random bit of java code, aka, the web container starting up. - run my little templates to transform current OFBiz data model XML files into Moqui ones and put those in a Moqui component in the Moqui runtime directory Sorry for the noob question, but does that mean that both ofbiz entityengine and moqui could talk to the same database backend(s), at the same time? This would be a basic PoC to get Moqui running inside OFBiz, and then we could start the real PoC of either a thunk layer as Adrian proposed, probably accessing the statically initialized Moqui ExecutionContextFactory since most OFBiz framework classes are statically initialized, or using the more dynamic initialization through the Moqui webroot webapp. Actually, a bit simpler, would be to just see if moqui can be added to the classpath, and loaded, before translating any datamodels. Once that is done, then have a method that translates the model definitions dynamically at load time, so that they are always kept in sync. Once this has proven, then that dynamic translation can be removed, and the output of it can become the new static definition of the model. The reason I suggest this way, is so that hot-deploy components(or other file modifications) that alter the entity definitions dynamically(extends-entity, whole new entity definitions) can also work transparently. For those who want a brief introduction to some of the differences between OFBiz Framework and Moqui Framework, see the OFBiz: How does it compare to Moqui? section at: http://www.moqui.org/framework/index.html That is an older document and isn't meant to be any sort of exhaustive list of the features of Moqui versus the features of OFBiz Framework, but gives a general idea about how some of the similar tools are different. For those who want to dive a bit deeper the Tutorial may be helpful: http://www.moqui.org/framework/docs/Tutorial.html For those who want to dive in neck deep the Making Apps with Moqui book is the more exhaustive reference to Moqui (though about 8 months old now and there are many new features, summarized in the ReleaseNotes.txt file for those curious): http://www.moqui.org/MakingAppsWithMoqui-1.0.pdf https://github.com/moqui/moqui/blob/master/ReleaseNotes.txt I would be happy to participate in this effort... if nothing else should be an interesting technical diversion. -David
Re: VOTE: Begin Replacing OFBiz Framework With Moqui
Hi David, very good to have you back in the project! Exiting times ahead! Regards, Hans On 28/04/15 15:39, David E. Jones wrote: +1 - with the clarification that to me begin replacing implies a PoC effort in a branch. I just saw this thread and need a little time to think over the best approach, but off the top of my head it would look something like: - add the moqui-framework-version.jar file and all dependent jars to a component directory under ofbiz/framework (these could go in the base or common components, but might be best separate for clarity); if needed update jars currently used in OFBiz where an older version is used (don't know if this is the case for any, mention for the sake of completeness) - add a Moqui runtime directory somewhere in the OFBiz directory tree (Moqui uses this for various things); this would contain the Moqui tools components (with the Tools and System apps) so we have a UI to look at Moqui internals, OFBiz data, etc - either in the Moqui runtime directory or as an OFBiz component add a webroot webapp; Moqui is designed to run in a single webapp, and I'd recommend this be separate from the existing OFBiz webapps for now; when this webapp loads it will init the Moqui ExecutionContextFactory, when it shuts down it will destroy it - because initializing Moqui when the webroot webapp starts may not be adequate, make sure the Moqui static init stuff is in place and working (in the Moqui.java class) - run my little templates to transform current OFBiz data model XML files into Moqui ones and put those in a Moqui component in the Moqui runtime directory This would be a basic PoC to get Moqui running inside OFBiz, and then we could start the real PoC of either a thunk layer as Adrian proposed, probably accessing the statically initialized Moqui ExecutionContextFactory since most OFBiz framework classes are statically initialized, or using the more dynamic initialization through the Moqui webroot webapp. For those who want a brief introduction to some of the differences between OFBiz Framework and Moqui Framework, see the OFBiz: How does it compare to Moqui? section at: http://www.moqui.org/framework/index.html That is an older document and isn't meant to be any sort of exhaustive list of the features of Moqui versus the features of OFBiz Framework, but gives a general idea about how some of the similar tools are different. For those who want to dive a bit deeper the Tutorial may be helpful: http://www.moqui.org/framework/docs/Tutorial.html For those who want to dive in neck deep the Making Apps with Moqui book is the more exhaustive reference to Moqui (though about 8 months old now and there are many new features, summarized in the ReleaseNotes.txt file for those curious): http://www.moqui.org/MakingAppsWithMoqui-1.0.pdf https://github.com/moqui/moqui/blob/master/ReleaseNotes.txt I would be happy to participate in this effort... if nothing else should be an interesting technical diversion. -David On 26 Apr 2015, at 07:44, Adrian Crum adrian.c...@sandglass-software.com wrote: As was discussed last week, there is some interest in replacing some (or all) of OFBiz with Moqui (http://www.moqui.org/framework/index.html). To the scope reasonable, I propose that we begin by converting the following parts of the OFBiz framework with Moqui: Entity Engine Service Engine Security Other parts of the OFBiz framework could be converted as well, but I think this would be a good starting point, and if is successful, then more of OFBiz can be converted later. I believe we can create a thunk component to help solve compatibility problems, but that is a separate discussion. I only mention it here in case compatibility concerns might influence a vote. -- Adrian Crum Sandglass Software www.sandglass-software.com
Re: VOTE: Begin Replacing OFBiz Framework With Moqui
On 28 Apr 2015, at 07:42, Adam Heath doo...@brainfood.com wrote: On 04/28/2015 03:39 AM, David E. Jones wrote: +1 - with the clarification that to me begin replacing implies a PoC effort in a branch. I just saw this thread and need a little time to think over the best approach, but off the top of my head it would look something like: - add the moqui-framework-version.jar file and all dependent jars to a component directory under ofbiz/framework (these could go in the base or common components, but might be best separate for clarity); if needed update jars currently used in OFBiz where an older version is used (don't know if this is the case for any, mention for the sake of completeness) There are 2 separate items in this bullet point. I'll talk about the second, updating jar versions. HAHAHAHAHAHAHA! I have discovered that ofbiz is using hc.apache.org(HttpClient), and commons-httpclient. The former is the newer, rewritten, rearchitected, replacement for the latter. The rest of the versioned jars are just as bad. Sounds like a small project of its own... - add a Moqui runtime directory somewhere in the OFBiz directory tree (Moqui uses this for various things); this would contain the Moqui tools components (with the Tools and System apps) so we have a UI to look at Moqui internals, OFBiz data, etc Do each of the separate moqui sub-tools need their own runtime folder? How difficult would it be to have $OFBIZ_HOME/runtime/$tool1, runtime/$tool2, etc? The Moqui runtime folder is similar to the one in OFBiz with component directories, and framework specific directories for classes, conf, db, elasticsearch, lib, log, template, and txlog. The Derby DB files go under the db directory (similar to in OFBiz) and the same is true for the Elasticsearch files (if you are running an embedded ES node with local storage). Some of these Moqui needs as separate folders, some can be combined with OFBiz ones, like the Derby and log dirs. - either in the Moqui runtime directory or as an OFBiz component add a webroot webapp; Moqui is designed to run in a single webapp, and I'd recommend this be separate from the existing OFBiz webapps for now; when this webapp loads it will init the Moqui ExecutionContextFactory, when it shuts down it will destroy it Wait. The webapp initializes the context factory? There isn't a separate way to do this? Does that mean Moqui is tied to a webapp? What kind of webapp? I hope it isn't servlets. You mention it as weboot. Does that mean it runs at the root of the webserver? This might be a noob question. Moqui is designed to facilitate deployment as a single WAR file. The Screen definitions in Moqui live in an hierarchy and you can add the root screen of each of your apps under the /apps screen, or under the root screen if you don’t want the /apps screen decorations. There are other ways to deploy it, like the static init approach mentioned below, but for most use this is by far the easiest. There is even support to add the runtime directory to the WAR file which gets picked up automatically when present, making it possible to throw the whole thing into one big WAR file and drop it into Tomcat or upload it to AWS ElasticBeanstalk or the myriad of similar hosting options. - because initializing Moqui when the webroot webapp starts may not be adequate, make sure the Moqui static init stuff is in place and working (in the Moqui.java class) Ah. So that means that means that moqui-component needs a container definition. Ignore the above then. I have never liked that ofbiz startup delays initialization of certain components until they are magically called from some random bit of java code, aka, the web container starting up. Even though Moqui has a real init/destroy lifecycle, many things are lazy-loaded and cached just like in OFBiz. This provides a lot of flexibility in both development and for production maintenance/etc. Moqui does have some cache warming code for entities, services, and screens that is on by default in production mode. - run my little templates to transform current OFBiz data model XML files into Moqui ones and put those in a Moqui component in the Moqui runtime directory Sorry for the noob question, but does that mean that both ofbiz entityengine and moqui could talk to the same database backend(s), at the same time? Yes. Initially this would be the easiest way to run them together. An early priority would be to use the Moqui transaction management (based on Bitronix or Atomikos, Bitronix being WAY faster and with the latest update far more reliable too) so that OFBiz Entity Engine and Moqui Entity Facade operations would share TX contexts. This would be a basic PoC to get Moqui running inside OFBiz, and then we could start the real PoC of either a thunk layer as Adrian proposed, probably accessing the statically initialized Moqui
Re: VOTE: Begin Replacing OFBiz Framework With Moqui
This is great news! Your participation will be invaluable! Adrian Crum Sandglass Software www.sandglass-software.com On 4/28/2015 9:39 AM, David E. Jones wrote: +1 - with the clarification that to me begin replacing implies a PoC effort in a branch. I just saw this thread and need a little time to think over the best approach, but off the top of my head it would look something like: - add the moqui-framework-version.jar file and all dependent jars to a component directory under ofbiz/framework (these could go in the base or common components, but might be best separate for clarity); if needed update jars currently used in OFBiz where an older version is used (don't know if this is the case for any, mention for the sake of completeness) - add a Moqui runtime directory somewhere in the OFBiz directory tree (Moqui uses this for various things); this would contain the Moqui tools components (with the Tools and System apps) so we have a UI to look at Moqui internals, OFBiz data, etc - either in the Moqui runtime directory or as an OFBiz component add a webroot webapp; Moqui is designed to run in a single webapp, and I'd recommend this be separate from the existing OFBiz webapps for now; when this webapp loads it will init the Moqui ExecutionContextFactory, when it shuts down it will destroy it - because initializing Moqui when the webroot webapp starts may not be adequate, make sure the Moqui static init stuff is in place and working (in the Moqui.java class) - run my little templates to transform current OFBiz data model XML files into Moqui ones and put those in a Moqui component in the Moqui runtime directory This would be a basic PoC to get Moqui running inside OFBiz, and then we could start the real PoC of either a thunk layer as Adrian proposed, probably accessing the statically initialized Moqui ExecutionContextFactory since most OFBiz framework classes are statically initialized, or using the more dynamic initialization through the Moqui webroot webapp. For those who want a brief introduction to some of the differences between OFBiz Framework and Moqui Framework, see the OFBiz: How does it compare to Moqui? section at: http://www.moqui.org/framework/index.html That is an older document and isn't meant to be any sort of exhaustive list of the features of Moqui versus the features of OFBiz Framework, but gives a general idea about how some of the similar tools are different. For those who want to dive a bit deeper the Tutorial may be helpful: http://www.moqui.org/framework/docs/Tutorial.html For those who want to dive in neck deep the Making Apps with Moqui book is the more exhaustive reference to Moqui (though about 8 months old now and there are many new features, summarized in the ReleaseNotes.txt file for those curious): http://www.moqui.org/MakingAppsWithMoqui-1.0.pdf https://github.com/moqui/moqui/blob/master/ReleaseNotes.txt I would be happy to participate in this effort... if nothing else should be an interesting technical diversion. -David On 26 Apr 2015, at 07:44, Adrian Crum adrian.c...@sandglass-software.com wrote: As was discussed last week, there is some interest in replacing some (or all) of OFBiz with Moqui (http://www.moqui.org/framework/index.html). To the scope reasonable, I propose that we begin by converting the following parts of the OFBiz framework with Moqui: Entity Engine Service Engine Security Other parts of the OFBiz framework could be converted as well, but I think this would be a good starting point, and if is successful, then more of OFBiz can be converted later. I believe we can create a thunk component to help solve compatibility problems, but that is a separate discussion. I only mention it here in case compatibility concerns might influence a vote. -- Adrian Crum Sandglass Software www.sandglass-software.com
Re: VOTE: Begin Replacing OFBiz Framework With Moqui
+1 - with the clarification that to me begin replacing implies a PoC effort in a branch. I just saw this thread and need a little time to think over the best approach, but off the top of my head it would look something like: - add the moqui-framework-version.jar file and all dependent jars to a component directory under ofbiz/framework (these could go in the base or common components, but might be best separate for clarity); if needed update jars currently used in OFBiz where an older version is used (don't know if this is the case for any, mention for the sake of completeness) - add a Moqui runtime directory somewhere in the OFBiz directory tree (Moqui uses this for various things); this would contain the Moqui tools components (with the Tools and System apps) so we have a UI to look at Moqui internals, OFBiz data, etc - either in the Moqui runtime directory or as an OFBiz component add a webroot webapp; Moqui is designed to run in a single webapp, and I'd recommend this be separate from the existing OFBiz webapps for now; when this webapp loads it will init the Moqui ExecutionContextFactory, when it shuts down it will destroy it - because initializing Moqui when the webroot webapp starts may not be adequate, make sure the Moqui static init stuff is in place and working (in the Moqui.java class) - run my little templates to transform current OFBiz data model XML files into Moqui ones and put those in a Moqui component in the Moqui runtime directory This would be a basic PoC to get Moqui running inside OFBiz, and then we could start the real PoC of either a thunk layer as Adrian proposed, probably accessing the statically initialized Moqui ExecutionContextFactory since most OFBiz framework classes are statically initialized, or using the more dynamic initialization through the Moqui webroot webapp. For those who want a brief introduction to some of the differences between OFBiz Framework and Moqui Framework, see the OFBiz: How does it compare to Moqui? section at: http://www.moqui.org/framework/index.html That is an older document and isn't meant to be any sort of exhaustive list of the features of Moqui versus the features of OFBiz Framework, but gives a general idea about how some of the similar tools are different. For those who want to dive a bit deeper the Tutorial may be helpful: http://www.moqui.org/framework/docs/Tutorial.html For those who want to dive in neck deep the Making Apps with Moqui book is the more exhaustive reference to Moqui (though about 8 months old now and there are many new features, summarized in the ReleaseNotes.txt file for those curious): http://www.moqui.org/MakingAppsWithMoqui-1.0.pdf https://github.com/moqui/moqui/blob/master/ReleaseNotes.txt I would be happy to participate in this effort... if nothing else should be an interesting technical diversion. -David On 26 Apr 2015, at 07:44, Adrian Crum adrian.c...@sandglass-software.com wrote: As was discussed last week, there is some interest in replacing some (or all) of OFBiz with Moqui (http://www.moqui.org/framework/index.html). To the scope reasonable, I propose that we begin by converting the following parts of the OFBiz framework with Moqui: Entity Engine Service Engine Security Other parts of the OFBiz framework could be converted as well, but I think this would be a good starting point, and if is successful, then more of OFBiz can be converted later. I believe we can create a thunk component to help solve compatibility problems, but that is a separate discussion. I only mention it here in case compatibility concerns might influence a vote. -- Adrian Crum Sandglass Software www.sandglass-software.com
Re: VOTE: Begin Replacing OFBiz Framework With Moqui
-1 currently for me If we are inspired of Moqui to improve OFBiz framework not to replace it, I will review my vote. For main framework components, I prefer keep the source code control under this community instead of load only jar Nicolas Le 26/04/2015 16:44, Adrian Crum a écrit : As was discussed last week, there is some interest in replacing some (or all) of OFBiz with Moqui (http://www.moqui.org/framework/index.html). To the scope reasonable, I propose that we begin by converting the following parts of the OFBiz framework with Moqui: Entity Engine Service Engine Security Other parts of the OFBiz framework could be converted as well, but I think this would be a good starting point, and if is successful, then more of OFBiz can be converted later. I believe we can create a thunk component to help solve compatibility problems, but that is a separate discussion. I only mention it here in case compatibility concerns might influence a vote.
Re: VOTE: Begin Replacing OFBiz Framework With Moqui
Generally I see three ways if I think of an combination of OFBiz and Moqui as already mentioned in the discussion so far: 1) „Replace“ the OFBiz Framework with Moqui 2) Replace parts of the OFBiz Framework with Moqui parts respectively update the OFBiz Framework in a Moqui manner 3) Migrate OFBiz applications and functionality, so that they be part of Mantle or standalone apps on base of Moqui Numbers 1 and 3 could lead to the same result, maybe the steps between are different or the approach or just the headline is another. Number 2 is more like thinking of optimization of the current framework, maybe by looking at Moqui, but there would be no Moqui integration in the end, only an updated OFBiz Framework. My vote for 1) is -1, because I don’t think it is a realistic project in terms of effort vs. benefit an with respect to the „customers“ of an „application framework OFBiz, this change could be an upgrade killer. For 2) there is generally a +1 where optimizations are reasonable, but this might be much less than a Moqui framework switch For 3) I say +1, also this would more be an parallel next OFBiz“ thing Martin Becker ecomify GmbH Am 27.04.2015 um 03:20 schrieb Adam Heath doo...@brainfood.com: Begin replacing ... is not an actional item. How can we vote on something that is ill-defined? Just saying. On 04/26/2015 08:09 PM, Ron Wheeler wrote: +1 for being too early. -1 for going ahead as a project +1 for a PoC and impact analysis Ron On 26/04/2015 6:46 PM, Pierre Smits wrote: First of all, a big thanks to Adrian for taking this step, this RtV (Request to Vote) to get clarity from the community. A lot has been said over the last week regarding adopting a new architecture for a future release. When discussions, like fire, die down it is good to find out where the community stands. And it seems that a saturation point was reached, as the last posting before Adam started to test the water of consensus was already 6 days ago. It seems that we are facing a chicken-and-egg situation here, as we can't vote on the new direction without knowing the impact of such path. And we can't establish insights about the impact without having tested the water and report about it. A PoC is a means to gain the insights. Based on the output of such an action, the community can reach a well-founded decision. But a PoC is not the only means to establish the insight. An in-dept comparative study of the two solutions (architecture, et all) might lead to such insights too. And a PoC can be done everywhere, even outside the OFBiz repository. The result of the impact analysis (whether from PoC or comparative study) could be recorded as JIRA issues. And all the registered JIRA issues together will be the starting point of a dev branch when the community votes for the adoption of a new architecture or not (based on those issues and other information). On the basis of current (high level) information regarding the impact, I say it is to early to vote for a migration. 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 Sun, Apr 26, 2015 at 10:56 PM, Michael Brohl michael.br...@ecomify.de wrote: Thank you for the clarification. I'll stick to my vote and my arguments then. Michael Brohl ecomify GmbH www.ecomify.de Am 26.04.15 um 22:33 schrieb Adrian Crum: No, it is not a vote for a POC. If the community agrees we need to make a change, then we can create a Jira issue, branch, POC, etc. No one is going to go to all that work if in the end the community says Nope, don't want it. Adrian Crum Sandglass Software www.sandglass-software.com
VOTE: Begin Replacing OFBiz Framework With Moqui
As was discussed last week, there is some interest in replacing some (or all) of OFBiz with Moqui (http://www.moqui.org/framework/index.html). To the scope reasonable, I propose that we begin by converting the following parts of the OFBiz framework with Moqui: Entity Engine Service Engine Security Other parts of the OFBiz framework could be converted as well, but I think this would be a good starting point, and if is successful, then more of OFBiz can be converted later. I believe we can create a thunk component to help solve compatibility problems, but that is a separate discussion. I only mention it here in case compatibility concerns might influence a vote. -- Adrian Crum Sandglass Software www.sandglass-software.com
Re: VOTE: Begin Replacing OFBiz Framework With Moqui
Is this a proposal for a POC? If so, where will this be done and what is estimated amount of time required to complete the POC. What will be required to complete te conversion if the POC is successful? What is the impact on the framework as a product if it is successful? Ron On 26/04/2015 10:44 AM, Adrian Crum wrote: As was discussed last week, there is some interest in replacing some (or all) of OFBiz with Moqui (http://www.moqui.org/framework/index.html). To the scope reasonable, I propose that we begin by converting the following parts of the OFBiz framework with Moqui: Entity Engine Service Engine Security Other parts of the OFBiz framework could be converted as well, but I think this would be a good starting point, and if is successful, then more of OFBiz can be converted later. I believe we can create a thunk component to help solve compatibility problems, but that is a separate discussion. I only mention it here in case compatibility concerns might influence a vote. -- Ron Wheeler President Artifact Software Inc email: rwhee...@artifact-software.com skype: ronaldmwheeler phone: 866-970-2435, ext 102
Re: VOTE: Begin Replacing OFBiz Framework With Moqui
First of all, a big thanks to Adrian for taking this step, this RtV (Request to Vote) to get clarity from the community. A lot has been said over the last week regarding adopting a new architecture for a future release. When discussions, like fire, die down it is good to find out where the community stands. And it seems that a saturation point was reached, as the last posting before Adam started to test the water of consensus was already 6 days ago. It seems that we are facing a chicken-and-egg situation here, as we can't vote on the new direction without knowing the impact of such path. And we can't establish insights about the impact without having tested the water and report about it. A PoC is a means to gain the insights. Based on the output of such an action, the community can reach a well-founded decision. But a PoC is not the only means to establish the insight. An in-dept comparative study of the two solutions (architecture, et all) might lead to such insights too. And a PoC can be done everywhere, even outside the OFBiz repository. The result of the impact analysis (whether from PoC or comparative study) could be recorded as JIRA issues. And all the registered JIRA issues together will be the starting point of a dev branch when the community votes for the adoption of a new architecture or not (based on those issues and other information). On the basis of current (high level) information regarding the impact, I say it is to early to vote for a migration. 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 Sun, Apr 26, 2015 at 10:56 PM, Michael Brohl michael.br...@ecomify.de wrote: Thank you for the clarification. I'll stick to my vote and my arguments then. Michael Brohl ecomify GmbH www.ecomify.de Am 26.04.15 um 22:33 schrieb Adrian Crum: No, it is not a vote for a POC. If the community agrees we need to make a change, then we can create a Jira issue, branch, POC, etc. No one is going to go to all that work if in the end the community says Nope, don't want it. Adrian Crum Sandglass Software www.sandglass-software.com
Re: VOTE: Begin Replacing OFBiz Framework With Moqui
On 04/26/2015 09:44 AM, Adrian Crum wrote: As was discussed last week, there is some interest in replacing some (or all) of OFBiz with Moqui (http://www.moqui.org/framework/index.html). To the scope reasonable, I propose that we begin by converting0 the following parts of the OFBiz framework with Moqui: Entity Engine Service Engine Security Other parts of the OFBiz framework could be converted as well, but I think this would be a good starting point, and if is successful, then more of OFBiz can be converted later. I believe we can create a thunk component to help solve compatibility problems, but that is a separate discussion. I only mention it here in case compatibility concerns might influence a vote. 0: needs more discussion.
Re: VOTE: Begin Replacing OFBiz Framework With Moqui
On 04/26/2015 02:27 PM, Adrian Crum wrote: No one is going to invest their time and effort in a POC unless they have the approval and support of the community. I don't think you're going to see a POC before a vote. I would.
Re: VOTE: Begin Replacing OFBiz Framework With Moqui
On 04/26/2015 06:13 PM, Adam Heath wrote: On 04/26/2015 02:27 PM, Adrian Crum wrote: No one is going to invest their time and effort in a POC unless they have the approval and support of the community. I don't think you're going to see a POC before a vote. I would. I haven't yet looked at Moqui either, so I'd be starting with a fresh view. This would also be a good way to get my feet wet. And, without even looking at the code, the first goal would be to have both running at the same time, in the same instance, with both being able to call each others service engines, and both database layers talking to the exact same structure. That would allow for services to be implemented in both, and would give a much clear incremental switchover.
Re: VOTE: Begin Replacing OFBiz Framework With Moqui
-1 (not binding) This is *not* a vote against moving to Moqui or replacing parts of OFBiz with Moqui or... I simply feel there is not enough discussion, deeper insights in the effects, a clear path how to do it etc., at least for me. I would prefer to have some scenarios described, take a deeper look at the effects, estimate the efforts and resources etc. No real company would set up a project of replacing their base products' framwork with another one based on the available informations and estimations. Begin replacing OFBiz Framework With Moqui: *-1* (right now) Begin to organise a PoC, have a deeper discussion and gather more facts: *+1* Michael ecomify GmbH www.ecomify.de Am 26.04.15 um 16:44 schrieb Adrian Crum: As was discussed last week, there is some interest in replacing some (or all) of OFBiz with Moqui (http://www.moqui.org/framework/index.html). To the scope reasonable, I propose that we begin by converting the following parts of the OFBiz framework with Moqui: Entity Engine Service Engine Security Other parts of the OFBiz framework could be converted as well, but I think this would be a good starting point, and if is successful, then more of OFBiz can be converted later. I believe we can create a thunk component to help solve compatibility problems, but that is a separate discussion. I only mention it here in case compatibility concerns might influence a vote. smime.p7s Description: S/MIME Cryptographic Signature
Re: VOTE: Begin Replacing OFBiz Framework With Moqui
Adrian, that's what I tried to say and what Ron asked: if it's a vote for a POC and not a final decision to replace OFBiz with Moqui: +1 The vote title is not about a POC but about a decision to begin replacing. For me this sounds like a difference. Might be a language problem on my side. Michael Brohl ecomify GmbH www.ecomify.de Am 26.04.15 um 21:27 schrieb Adrian Crum: No one is going to invest their time and effort in a POC unless they have the approval and support of the community. I don't think you're going to see a POC before a vote. Adrian Crum Sandglass Software www.sandglass-software.com On 4/26/2015 6:39 PM, Michael Brohl wrote: -1 (not binding) This is *not* a vote against moving to Moqui or replacing parts of OFBiz with Moqui or... I simply feel there is not enough discussion, deeper insights in the effects, a clear path how to do it etc., at least for me. I would prefer to have some scenarios described, take a deeper look at the effects, estimate the efforts and resources etc. No real company would set up a project of replacing their base products' framwork with another one based on the available informations and estimations. Begin replacing OFBiz Framework With Moqui: *-1* (right now) Begin to organise a PoC, have a deeper discussion and gather more facts: *+1* Michael ecomify GmbH www.ecomify.de Am 26.04.15 um 16:44 schrieb Adrian Crum: As was discussed last week, there is some interest in replacing some (or all) of OFBiz with Moqui (http://www.moqui.org/framework/index.html). To the scope reasonable, I propose that we begin by converting the following parts of the OFBiz framework with Moqui: Entity Engine Service Engine Security Other parts of the OFBiz framework could be converted as well, but I think this would be a good starting point, and if is successful, then more of OFBiz can be converted later. I believe we can create a thunk component to help solve compatibility problems, but that is a separate discussion. I only mention it here in case compatibility concerns might influence a vote. smime.p7s Description: S/MIME Cryptographic Signature
Re: VOTE: Begin Replacing OFBiz Framework With Moqui
No, it is not a vote for a POC. If the community agrees we need to make a change, then we can create a Jira issue, branch, POC, etc. No one is going to go to all that work if in the end the community says Nope, don't want it. Adrian Crum Sandglass Software www.sandglass-software.com On 4/26/2015 9:16 PM, Michael Brohl wrote: Adrian, that's what I tried to say and what Ron asked: if it's a vote for a POC and not a final decision to replace OFBiz with Moqui: +1 The vote title is not about a POC but about a decision to begin replacing. For me this sounds like a difference. Might be a language problem on my side. Michael Brohl ecomify GmbH www.ecomify.de Am 26.04.15 um 21:27 schrieb Adrian Crum: No one is going to invest their time and effort in a POC unless they have the approval and support of the community. I don't think you're going to see a POC before a vote. Adrian Crum Sandglass Software www.sandglass-software.com On 4/26/2015 6:39 PM, Michael Brohl wrote: -1 (not binding) This is *not* a vote against moving to Moqui or replacing parts of OFBiz with Moqui or... I simply feel there is not enough discussion, deeper insights in the effects, a clear path how to do it etc., at least for me. I would prefer to have some scenarios described, take a deeper look at the effects, estimate the efforts and resources etc. No real company would set up a project of replacing their base products' framwork with another one based on the available informations and estimations. Begin replacing OFBiz Framework With Moqui: *-1* (right now) Begin to organise a PoC, have a deeper discussion and gather more facts: *+1* Michael ecomify GmbH www.ecomify.de Am 26.04.15 um 16:44 schrieb Adrian Crum: As was discussed last week, there is some interest in replacing some (or all) of OFBiz with Moqui (http://www.moqui.org/framework/index.html). To the scope reasonable, I propose that we begin by converting the following parts of the OFBiz framework with Moqui: Entity Engine Service Engine Security Other parts of the OFBiz framework could be converted as well, but I think this would be a good starting point, and if is successful, then more of OFBiz can be converted later. I believe we can create a thunk component to help solve compatibility problems, but that is a separate discussion. I only mention it here in case compatibility concerns might influence a vote.
Re: VOTE: Begin Replacing OFBiz Framework With Moqui
Thank you for the clarification. I'll stick to my vote and my arguments then. Michael Brohl ecomify GmbH www.ecomify.de Am 26.04.15 um 22:33 schrieb Adrian Crum: No, it is not a vote for a POC. If the community agrees we need to make a change, then we can create a Jira issue, branch, POC, etc. No one is going to go to all that work if in the end the community says Nope, don't want it. Adrian Crum Sandglass Software www.sandglass-software.com smime.p7s Description: S/MIME Cryptographic Signature
Re: VOTE: Begin Replacing OFBiz Framework With Moqui
+1 for being too early. -1 for going ahead as a project +1 for a PoC and impact analysis Ron On 26/04/2015 6:46 PM, Pierre Smits wrote: First of all, a big thanks to Adrian for taking this step, this RtV (Request to Vote) to get clarity from the community. A lot has been said over the last week regarding adopting a new architecture for a future release. When discussions, like fire, die down it is good to find out where the community stands. And it seems that a saturation point was reached, as the last posting before Adam started to test the water of consensus was already 6 days ago. It seems that we are facing a chicken-and-egg situation here, as we can't vote on the new direction without knowing the impact of such path. And we can't establish insights about the impact without having tested the water and report about it. A PoC is a means to gain the insights. Based on the output of such an action, the community can reach a well-founded decision. But a PoC is not the only means to establish the insight. An in-dept comparative study of the two solutions (architecture, et all) might lead to such insights too. And a PoC can be done everywhere, even outside the OFBiz repository. The result of the impact analysis (whether from PoC or comparative study) could be recorded as JIRA issues. And all the registered JIRA issues together will be the starting point of a dev branch when the community votes for the adoption of a new architecture or not (based on those issues and other information). On the basis of current (high level) information regarding the impact, I say it is to early to vote for a migration. 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 Sun, Apr 26, 2015 at 10:56 PM, Michael Brohl michael.br...@ecomify.de wrote: Thank you for the clarification. I'll stick to my vote and my arguments then. Michael Brohl ecomify GmbH www.ecomify.de Am 26.04.15 um 22:33 schrieb Adrian Crum: No, it is not a vote for a POC. If the community agrees we need to make a change, then we can create a Jira issue, branch, POC, etc. No one is going to go to all that work if in the end the community says Nope, don't want it. Adrian Crum Sandglass Software www.sandglass-software.com -- Ron Wheeler President Artifact Software Inc email: rwhee...@artifact-software.com skype: ronaldmwheeler phone: 866-970-2435, ext 102
Re: VOTE: Begin Replacing OFBiz Framework With Moqui
Begin replacing ... is not an actional item. How can we vote on something that is ill-defined? Just saying. On 04/26/2015 08:09 PM, Ron Wheeler wrote: +1 for being too early. -1 for going ahead as a project +1 for a PoC and impact analysis Ron On 26/04/2015 6:46 PM, Pierre Smits wrote: First of all, a big thanks to Adrian for taking this step, this RtV (Request to Vote) to get clarity from the community. A lot has been said over the last week regarding adopting a new architecture for a future release. When discussions, like fire, die down it is good to find out where the community stands. And it seems that a saturation point was reached, as the last posting before Adam started to test the water of consensus was already 6 days ago. It seems that we are facing a chicken-and-egg situation here, as we can't vote on the new direction without knowing the impact of such path. And we can't establish insights about the impact without having tested the water and report about it. A PoC is a means to gain the insights. Based on the output of such an action, the community can reach a well-founded decision. But a PoC is not the only means to establish the insight. An in-dept comparative study of the two solutions (architecture, et all) might lead to such insights too. And a PoC can be done everywhere, even outside the OFBiz repository. The result of the impact analysis (whether from PoC or comparative study) could be recorded as JIRA issues. And all the registered JIRA issues together will be the starting point of a dev branch when the community votes for the adoption of a new architecture or not (based on those issues and other information). On the basis of current (high level) information regarding the impact, I say it is to early to vote for a migration. 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 Sun, Apr 26, 2015 at 10:56 PM, Michael Brohl michael.br...@ecomify.de wrote: Thank you for the clarification. I'll stick to my vote and my arguments then. Michael Brohl ecomify GmbH www.ecomify.de Am 26.04.15 um 22:33 schrieb Adrian Crum: No, it is not a vote for a POC. If the community agrees we need to make a change, then we can create a Jira issue, branch, POC, etc. No one is going to go to all that work if in the end the community says Nope, don't want it. Adrian Crum Sandglass Software www.sandglass-software.com
