It might work fine putting the proposed interfaces and XSDs in wiki pages, but seems really cumbersome compared to a code repository!
-David > On 17 Oct 2015, at 13:39, Ron Wheeler <[email protected]> wrote: > > This seems like a very sound approach and something that can be started in > the wiki. > That way no one will be tempted to start coding before we know what to code. > > > If the first things to be coded (even if the wiki is the repo) are interfaces > and XML schemas, we should be able to divide up the implementation classes > among a wide number of committers while still maintaining a sense of > confidence that the result will be what was agreed upon. > > It will also allow us to validate: > 1) Is there a consensus about the design and function of a new framework > 2) Is there enough of a community to actually build one. > > Can we start with the pages that Adrian wrote way back then, as a basic > outline of the components of a framework? > https://cwiki.apache.org/confluence/display/OFBADMIN/Another+Framework+Vision > > > Ron > > > On 17/10/2015 2:07 PM, David E. Jones wrote: >> 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 <[email protected]> >>> 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 <[email protected]> wrote: >>>> >>>>>> On 15 Oct 2015, at 07:58, Adrian Crum < >>>>> [email protected]> 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: [email protected] >>> skype: ronaldmwheeler >>> phone: 866-970-2435, ext 102 >>> >> > > > -- > Ron Wheeler > President > Artifact Software Inc > email: [email protected] > skype: ronaldmwheeler > phone: 866-970-2435, ext 102 >
