I think the Moqui Framework is already to a point where migration of OFBiz business-level artifacts could begin immediately.
Doing a migration like this would bring up other issues... including whether or not to clean up the data model and services while at it, especially rewriting messier parts of OFBiz like the ShoppingCart* objects and order processing stuff in general. If you want to stick with everything as-is and just do a migration, that should actually be much less work than you might think. I have some FTL templates to transform entity and service definitions, and a partial template for simple-methods. Similar templates could be made for screens and forms, though they are more complicated and may require more manual work. Things like groovy scripts and Java classes will also require a bit more work, but many patterns are similar so it would be much less work than moving to an object-relational sort of framework (ie Hibernate/JPA type of thing). While on the topic, some notes about things I saw in some related threads: 1. the DSL/Helper class effort is in principle just an improved API for framework tools; the OFBiz framework tools were originally implemented independently, and based on a LOT of static methods and static initialization, resulting in an "API" that is made up of a bunch of independent objects that I've found are opaque even to developers with years of OFBiz experience (ie they are not aware of functionality because it is so hard to find); the Moqui API takes care of this problem with an API designed to actually be an API as opposed to a bunch of independent classes that evolved; for more info on that, see: http://www.moqui.org/apiJavadoc/index.html ... and the central object of the API (that also has contextual details for the current request/user/etc): http://www.moqui.org/apiJavadoc/org/moqui/context/ExecutionContext.html Here are some quick examples of how this looks in actual use (from the sendEmailTemplate.groovy script; sorry for the wrapping): def emailTemplate = ec.entity.makeFind("moqui.basic.email.EmailTemplate").condition("emailTemplateId", emailTemplateId).one() String bodyText = ec.screen.makeRender().rootScreen(emailTemplate.bodyScreenLocation).renderMode("text").render() Map cemParms = [sentDate:ec.user.nowTimestamp, subject:subject, body:bodyHtml, fromAddress:emailTemplate.fromAddress, toAddresses:toAddresses, ccAddresses:emailTemplate.ccAddresses, bccAddresses:emailTemplate.bccAddresses, contentType:"text/html", emailTemplateId:emailTemplateId,fromUserId:ec.user.userId] ec.service.sync().name("create", "moqui.basic.email.EmailMessage").parameters(cemParms).call() 2. consolidating OFBiz data model and services into a single component: this is the way the Mantle UDM and USL are currently organized, though they are restricted to very generic stuff and application-specific extensions would live in the corresponding application 3. running in a single webapp: while this isn't necessary with Moqui, the Moqui Screens are a combination of the controller.xml entries for the particular screen and the OFBiz Screen Widget, and are hierarchical instead of being flat like the request-map URIs in OFBiz; this allows apps to plug into a screen hierarchy from separate places (by explicit inclusion, a database record, or implicitly by directory structure) ================================ This might actually be good in a separate email, but anyway... The Moqui Framework would be a separate project from OFBiz, and while some OFBiz committers could certainly become moderators for Moqui that would be based on their personal efforts and merits and not anything to do with what happens or has happened in OFBiz. Moqui has a lot more extension points built-in than the OFBiz Framework, so you can actually do quite a bit without changing the framework itself. For cases where changes are needed (or wanted) to Moqui itself they would go through the normal feature request and patch submission process for Moqui to be reviewed by a moderator. Initially this would be me, and I obviously have some skin invested in an effort like this so I'd try to be responsive as possible (I have been so far with Moqui, but most of the time it has had light traffic so I've been able to get things reviewed and changed/fixed within a couple of days). One of the easiest ways to do that is with a pull request on GitHub. In fact, if the OFBiz variation of the Moqui Framework was managed on GitHub you could customize things there as desired while still being able to submit changes back to Moqui and get updates from Moqui so that OFBiz can more easily participate in the Moqui community. In git terminology this would actually be a "fork", and I think is what Jacopo was talking about. Still, for the most part my guess is that this would not be needed and I'd recommend starting with just the jar files (or even just the war file) and not set things up for easily changing the framework until the need for doing so is well established. For this interested in considering Moqui for use in OFBiz, the tutorial and framework intro docs are probably the best places to start, and the Run/Deploy doc is also helpful (BTW, the moqui.org site is actually running on Moqui, and the tutorial and run/deploy docs are actually cwiki documents (confluence-style wiki text)): http://www.moqui.org/framework/docs/Tutorial.html http://sourceforge.net/projects/moqui/files/IntroductionToMoquiFramework-1.0.1.pdf/download http://www.moqui.org/framework/docs/RunDeploy.html Anyway, sorry for the delay in responding to this. I'm still a bit busy on contracts and I only catch up on the OFBiz mailing lists every week or so. -David Jacopo Cappellato wrote: > On Mar 2, 2012, at 7:50 AM, Hans Bakker wrote: > >> Jacopo, >> >> You would even consider forking? > > From Wikipedia [*]: > > "[...] More recently, distributed revision control (DVCS) tools have > popularised a less emotive use of the term "fork", blurring the distinction > with "branch". With a DVCS such as Mercurial or Git, the normal way to > contribute to a project is to first branch the repository, and later seek to > have your changes integrated with the main repository. Sites such as Github, > Bitbucket and Launchpad provide free DVCS hosting expressly supporting > independent branches, such that the technical, social and financial barriers > to forking a source code repository are massively reduced." > > In order of preference (descending), here are the options I see for the > future of the OFBiz framework: > > 1) develop a great Apache OFBiz framework 2.0 within the OFBiz community; > then release it separately from the Apache OFBiz ERP > 2) greatly clean up and improve the existing framework (I was not sure if > this could go at #1) > 3) if the above will not be possible (frankly speaking, in the committers > group, apart from David, none of us ever implemented with success an open > source framework) we should also consider to drop the existing code and have > our community focusing on the ERP part (as Hans seems to advocate); at this > point Moqui would be the most natural choice; if we will ever go with this > path a great exchange of information will have to happen between the two > projects: for example OFBiz will probably have to ask the Moqui framework to > evolve some of its features; given the current nature of the Moqui project, I > doubt that the OFBiz committers will be ever invited as committers there; if > Moqui will be our choice, I see two possibilities: > 3.a) we base the Apache OFBiz ERP on a release of Moqui: this will only be > possible if Moqui release will have all the features we need (and if Moqui > community will be interested in getting contribution to evolve in the > direction required by OFBzi) > 3.b) if 3.a will not be possible because OFBiz will need some features that > Moqui community will not consider as a good fit for Moqui, then, under the > guidance and bless of David, we could work on a fork: get the code from a > Moqui release, import in our repository and add to it, in a controlled way, > the features we need; of course this should be always kept as close as > possible to the original code; we could synch our custom code with every new > Moqui release; I was not thinking about *stealing* code to Moqui and the fact > that David is both the founder of OFBiz and of Moqui and he is both in the > OFBiz PMC and the leader of the Moqui project will definitely facilitate > this; but it will be still an ugly solution but for example when you said: > "My proposal is that Apache OFBiz will be in the future just the ERP system > based on many opensource products like birt and also Moqui...." you are > actually implying that the ERP applications will be able to use Birt... but > this requires some sort of framework and what would you do if Moqui will not think that Birt is a good fit for them? > 4) if Moqui will not be a good option we may consider other frameworks (?), > but it will be difficult, or continue with what we have > > Jacopo > > > > [*]: http://en.wikipedia.org/wiki/Fork_(software_development)
