On Apr 2, 2011, at 12:39 PM, Adrian Crum wrote: > I agree 100% with the end result - OFBiz running on a separate application > framework. The question is: How do we get from here to there? That is what my > original reply was trying to address.
That is the real trick isn't it... The idea of creating release branch and then working in the trunk to start migrating to Moqui is an interesting one. The fastest route to the migration would involve basically allowing much of it to be broken rather than trying to juggle both frameworks as application artifacts are migrated from one to the other. However, if we do that then the trunk wouldn't be reliable at all and groups with more immediate needs would simply not be able to use it. Maybe the project is mature enough now that a stable release branch would be adequate for many users and the community behind the framework migration could work independently of that. Another option would be to create a "fork". That would allow the current OFBiz on the current OFBiz Framework to continue under development by those interested, and for those interested in a migrating to the Moqui Framework they could do it as a separate project without worrying about the legacy and backward compatibility issues, and ensuring proper functioning (which would allow for a more traditional develop and release model too, so it could go through normal alpha/beta/RC/etc cycles). The better way, I don't know... I guess it depends on how many in the community fall into each camp (needing something continuable workable to base their efforts on, versus being able to work on something that won't be ready for at least a number of months). > One other thing to keep in mind during this discussion: The Moqui framework > is under the control of a single person, and possibly in the future, a small > group of committers. Will the Moqui community have the necessary resources to > support OFBiz once a commitment is made to use it instead of our own > framework? That is correct, it is a separate project with a different management and resource model. There are currently around 100 such libraries in OFBiz, and by size Moqui Framework wouldn't be the biggest. There would be dramatic dependencies on it of course, and I guess that's where your concern is based. As fas as support goes, those involved with Moqui don't need to support OFBiz or the OFBiz community, they just need to support the Moqui Framework. It's functionality that needs to be supported in this case, not people. Because of the more traditional release cycle of Moqui Framework, and because it has a well-defined scope, it should be used as-is and upgraded periodically just like any other library. Chances are OFBiz would benefit from a different build and deploy model than the default Moqui one, and probably different screen/form output templates (perhaps even a different XML Actions output template), and possibly even additional resource referencers, template renderers, script runners, etc. But, that is all external to the Moqui Framework. Anyway, the point is that bug-fixing will be the primary need for the OFBiz Community, and that is the need for all other Moqui Framework users as well. On a side note, there is a great benefit to OFBiz in using an external framework in that the development model changes from all sorts of random changes going into the framework as needed to a more defined and thought out change process to preserve a more generic and flexible set of tools. I don't think there is any way you can get that benefit without the clear segregation between both the projects and the communities behind them. -David > > -Adrian > > On 4/2/2011 11:28 AM, David E Jones wrote: >> What I mean is throw out the OFBiz Framework and migrate the applications >> and specialpurpose components to run on Moqui Framework, and perhaps even >> incorporate the Mantle stuff too (mostly UDM, USL). >> >> After that OFBiz would be the applications project it was meant to be >> originally, as opposed to the framework + applications that is became out of >> necessity. >> >> -David >> >> >> On Apr 2, 2011, at 12:21 PM, Adrian Crum wrote: >> >>> What does "migrate to use Moqui Framework" mean? Maybe I'm not >>> understanding what you're proposing. >>> >>> -Adrian >>> >>> On 4/2/2011 11:18 AM, David E Jones wrote: >>>> Adrian, >>>> >>>> Just to see if I understand correctly what you wrote: are you proposing to >>>> make changes to the OFBiz Framework using code and ideas from the Moqui >>>> Framework? >>>> >>>> If so, why not just migrate to use Moqui Framework? >>>> >>>> -David >>>> >>>> >>>> On Apr 2, 2011, at 10:15 AM, Adrian Crum wrote: >>>> >>>>> Based on the previous discussion we had on this subject, I would suggest >>>>> we create an 11.x branch, and then start discussing a road map for >>>>> porting the changes from Moqui to OFBiz. I hope to be available to help >>>>> in November. >>>>> >>>>> -Adrian >>>>> >>>>> >>>>> On 4/1/2011 11:09 PM, David E Jones wrote: >>>>>> I still don't know if or how all of this will turn out, but here is the >>>>>> latest on the changes I've been wanting to make in the OFBiz Framework, >>>>>> but gave up on doing directly in OFBiz about a year and a half ago. The >>>>>> redesigned framework is a separate project that is now in beta (I just >>>>>> did the release today): >>>>>> >>>>>> http://www.moqui.org/ >>>>>> >>>>>> The Moqui Framework is now feature-complete for the planned feature set >>>>>> of the 1.0 version. There are details about this in the release notes, >>>>>> including everything in this release and the previous 3 releases, plus a >>>>>> list of features not to be included in 1.0. >>>>>> >>>>>> At this point the framework is far enough along that it is a clear >>>>>> demonstration of the changes that I would like to see in OFBiz, but that >>>>>> are difficult to do in a project with such a mature community and a >>>>>> large set of software that depends on it. Some of the main things are >>>>>> how the security and authorization are done, how the API is organized, >>>>>> the separation between framework and non-framework runtime artifacts, >>>>>> the deployment model (described in detail in the RunDeploy.txt file in >>>>>> the project), the way templates are used for simple-methods (XML Actions >>>>>> in Moqui) and the form/screen/etc widgets (XML Screens, Forms in Moqui), >>>>>> and how the web "controller" in OFBiz could be combined with screens and >>>>>> made hierarchical to introduce a lot of flexibility and far better >>>>>> organization of applications (less files open, easier to find things, >>>>>> automatic menu creation, per-used menu items/subscreens, and much more). >>>>>> >>>>>> Now that the beta is out the next step is to start building more >>>>>> real-world applications with it (so far the framework just has an >>>>>> example app and some basic tools built on it), and those will act as >>>>>> test cases as well. I don't have any intention to create another project >>>>>> like OFBiz that is a comprehensive ERP/CRM/etc/etc/etc system, and >>>>>> instead I'm hoping those will be separate project. >>>>>> >>>>>> However, I am working on a project to act as a basis for various >>>>>> applications that will share the same data model, common services, and >>>>>> derive from a common set of stories too. This project is called >>>>>> "Mantle". To see how this all fits together, check out the home page on >>>>>> the moqui.org site which has a diagram that includes these things. There >>>>>> is also a link to the github repository that has the Mantle UDM >>>>>> (Universal Data Model) progress so far. >>>>>> >>>>>> Back to the first comment: I don't know all of this will turn out. In a >>>>>> way it would be interesting to have OFBiz migrate to use these things, >>>>>> but that may not be of interest to very many in the community, so I >>>>>> won't be too surprised if that never happens. I've already heard from a >>>>>> couple of people who have proposed this idea, and I know some others >>>>>> would probably be very against it. >>>>>> >>>>>> On the other hand, if anyone is curious about such a thing, now it's >>>>>> possible to get an idea of what it might look like by look at the Moqui >>>>>> Framework and the example application and such. >>>>>> >>>>>> -David >>>>>> >>>>>> >
