This message has a lot of the right questions to ask about a new framework.
A big part of why the OFBiz framework suffers is because it was never planned in its entirety from the beginning, it is VERY much an emergent design as opposed to an intentional one. The interest bits start appearing with intentional design, and for anyone serious about getting into a fresh framework rewrite I’d highly recommend doing the same thing I did with Moqui: define Java interfaces for the API and an XML schema (XSD files) for the intended XML files. The XML schema might be the same as the current one, though there is room for improvement in the current OFBiz XML files and the eventual framework would be much better if these are reconsidered as well. You can see the Moqui interfaces here: https://github.com/moqui/moqui/tree/master/framework/src/api/java/org/moqui The central object at runtime, ie for most application code, is the implementation of the ExecutionContext interface. The whole API is structured around this: https://github.com/moqui/moqui/blob/master/framework/src/api/java/org/moqui/context/ExecutionContext.java There is also a JavaDoc generated and available on moqui.org, might be easier to read for some: http://www.moqui.org/javadoc/index.html http://www.moqui.org/javadoc/org/moqui/context/ExecutionContext.html I include these links because they might be useful for ideas or even as a starting point for a next generation OFBiz framework API (take or leave each method/etc as you wish). The nice thing about creating Java interfaces as opposed to a document is they are more clear and concise, and can be actually used in the framework implementation once interested community participants have reviewed it. This doesn’t require nearly as much work as implementing the beast and is a great way to communicate concepts, so for anyone really serious about a framework rewrite in OFBiz I’d highly recommend this specific effort. The other details like which tools (other open source projects and such) to use is less important. On the other hand if using something like Spring is a serious consideration it would change the API dramatically, and a lot of the design ideas as well (I’d recommend against this BTW, the Spring ecosystem is its own thing and VERY different conceptually from OFBiz). -David > On 16 Oct 2015, at 08:47, Ron Wheeler <rwhee...@artifact-software.com> wrote: > > Before we start to decide who can access code, we need to decide on a roadmap > for the new framework. > How different will the API be from the current framework in each of the areas > that the framework will offer services? > > How modular will it be? > Foundation identifies > - Core with 3 main areas of functionality. Can they be separated into > separate projects with clean interfaces? are there more projects such as > authentication, persistence, logging and audit (see below) that are shared > across the Foundation Core high level features. > - Script > - Imex > - Connect - seems to a number of projects here that could be tackled > separately. > Is this it? > > Will there be an application isolation layer that will support OFBiz's > current interaction with the Framework. This should also be a separate > project where OFBiz knowledge is really valuable. > > What will go underneath the covers? Spring-Boot , Spring JPA, Hibernate, etc. > > How many containers will be supported. Tomcat, Jetty, Glassfish, Spring-Boot. > > How many persistence options will be supported? SQL, No-SQL > > How many authentication services will be supported - internal, LDAP, Oauth, > Google, LinkedIn, Facebook. > > What administration functions will be offered? How? JConsole, REST, > browser/mobile apps. > > How delivered? Installer, Docker image, VM image, > > What demo apps? > > What test framework(s)? Test Applications. > > What would be a reasonable set of functionality to be released in version > 1.0? Minimum useful framework. > > How many people would it take to do this in a reasonable timeframe? > > Ron > > > On 16/10/2015 3:41 AM, Pierre Smits wrote: >> On Fri, Oct 16, 2015 at 5:31 AM, David E. Jones <d...@me.com> wrote: >> >>> >>>> On 15 Oct 2015, at 07:58, Adrian Crum < >>> adrian.c...@sandglass-software.com> wrote: >>>> Keep in mind that much of David's code in OFBiz has been rewritten. So >>> yes, we CAN do a better job than him. >>> >>> I think there’s a name for this logical fallacy… >>> >>> And this could also be called a logical fallacy. But let us not make it >> into a pissing contest again, like we had in the past regarding the >> opposing viewpoints on this. >> >> >>>> Also keep in mind that Moqui duplicates some of the problems I listed - >>> so by using Moqui, we keep the same problems instead of fixing them. >>> >>> Could you be more specific, other than the type conversion stuff you >>> mentioned many years ago (which I fully disagree with)? >>> >>> This is not about who is right or wrong, but where the community wants to >> go. >> >> I understand the reluctance of the community, because the impact will be >> huge. When looking at the data in OpenHub I see OFBiz having an estimate >> effort spend of 519 person years vs 6 for the combined >> Moqui-Mantle-HiveMindPM-PopCommerce suite. And one of the reasons behind it >> is simple: Many more have worked on OFBiz (from day 1) than on the Moqui >> suite. One could even argue that both directions took the same number of >> years in duration to get where they are now. Without all the experiences >> regarding the OFBiz product there couldn't have been an evolution called >> the Moqui suite. >> >> Coming back to opting for a new direction, as Scott has stated we can have >> this in a separate code repository (subproject, like many other Apache >> projects do their work) even combined with a new JIRA an Wiki under the >> umbrella of the OFBiz project. Based on the comments provided, this seems >> like a logical choice to ensure that adopters of the current solution will >> keep the support of the community while at the same time ensuring >> containment of the new approach. >> >> But these are mere technical, supportive aspects. The more important issue >> is what this new solution will encompass. There are talks of a rewrite, >> which sounds like reinvention of the wheel. But I guess it is not like >> that. Yet, taking decisions based on a few one-pagers (e.g. >> http://www.sandglass-software.com/products/sandglass/documents/Foundation_Brochure.pdf) >> are seldom done. Maybe it works for a single person, but I doubt it will >> make a community fly. >> >> Whether fix or rewrite, choices will be made regarding the supporting 3rd >> party libraries/solutions and the community needs to understand the impact >> to get behind it. So before we embark on the coding trip, let us get into >> trying to define a bit more what the new solution will encompass and get >> consensus on that. >> >> Another issue regarding getting the community behind behind this new effort >> is this: 'restrict access to the new code'. I guess this meant restrict >> write access. Though understandable from a avoidance of dilution/scope >> creep point of view, I see this as a wrong direction. This 'proposed' >> exclusion of contributors of the kind will bring us back to where this >> project came from: discrimination and favouritism. I even doubt that this >> is possible under the current principles of the ASF. >> Given that this is an enormous undertaking, we need to get as many on board >> as possible. Not only to ensure that the decisions (at each level) will get >> consensus, but also the ensure that every aspect down the line will get >> addressed (e.g. documentation, test definitions, marketing/promotions, etc) >> in order to get this kite flying. >> >> Best regards, >> >> Pierre Smits >> >> *OFBiz Extensions Marketplace* >> http://oem.ofbizci.net/oci-2/ >> > > > -- > Ron Wheeler > President > Artifact Software Inc > email: rwhee...@artifact-software.com > skype: ronaldmwheeler > phone: 866-970-2435, ext 102 >
