That shouldn't be a problem. We have a consensus model to ensure that the right code goes in the code repositories.
Best regards, Pierre Smits *OFBiz Extensions Marketplace* http://oem.ofbizci.net/oci-2/ On Tue, Oct 20, 2015 at 8:54 AM, Ron Wheeler <[email protected] > wrote: > The problem with using a code repository is that it would open up the code > repo to lots of people or prevent a lot of people from working on the > project(s). > > Ron > > > On 20/10/2015 12:54 AM, David E. Jones wrote: > >> 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 >>> >>> >> > > -- > Ron Wheeler > President > Artifact Software Inc > email: [email protected] > skype: ronaldmwheeler > phone: 866-970-2435, ext 102 > >
