Jacopo Cappellato wrote: >> 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. >> > > It will be very difficult to rewrite existing stuff, and doing this > before or after the migration wouldn't change its complexity. For > this reason I think we can keep this topic out of this thread for > now. However, instead of rewriting, we could clean up what we have in > OFBiz before the migration... especially if this could simplify the > migration or make the existing code better organized. For example, in > another thread I was proposing to merge the existing application > components into one, with possibly one webapp and less (and more > consolidated) files: this may seem a huge effort but it may not be, > because it could be done in baby steps with a lot of string > replacements, moving/renaming files around etc... we could even > create some scripts to simplify the effort. But again, also this > could be done before/after the migration (or never).
Some of it could certainly be improved with a rewrite, or perhaps more of a serious refactor. For example, using the database for shopping cart data instead of an object in the session would be far more flexible for a variety of order processing apps, especially outside of the normal ecommerce submit-all-at-once flow. But yes, this introduces another whole big set of issues and discussions. Actually, frankly I'm surprised there is consideration of any major framework changes, let alone moving to a new framework, because so much effort is required to update or migrate all of the existing business artifacts. That has killed a lot of framework enhancement efforts over the years. The main trick I'd see with combining webapps in the current ofbiz/applications components is the request-map uri and view-map name namespaces, ie the issue with duplicate names pointing to different events and screens and such. In Moqui these controller files would go away and the request-map and view-map data goes into the screen definitions, but I can't think of any changes that could be made now and supported by OFBiz to help move toward this. >> 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). > > This doesn't help much to make me comfortable :-) David, it may help > if you could list a series of tasks (if any) we could perform in one > of the OFBiz application components to make it more ready to be > migrated: the tasks should ideally be doable in steps, and after each > step the component should be usable in the existing OFBiz framework; > but the code should be more compliant with the future layout of Moqui > (or with what the migration scripts will expect); for example we > could: * merge/split service, entity, screen/forms definitions in > one/more files * merge Groovy scripts into one file with several > methods (one per data preparation script) * merge/split Java classes > for services * merge/split xml files with services * etc. etc.. As for what can be done in advance to prepare for it, I don't think that splitting or combining files is too big a deal because that can be done by a tool more easily than by a human. The main area where Moqui differs from OFBiz Framework in terms of artifacts per file is the screens. In Moqui there is one screen per file as opposed to multiple screens per file, and they are hierarchical as opposed to flat (or more of a network for decoration/inclusion/etc). This could be done manually, but it could also be done by a tool and perhaps more easily. -David
