Why A Framework Rewrite Is Necessary
Locked
123
123
 
|
+1
程序羊
|
|
In reply to this post by Adrian Crum-3
Hi Adrian,
Ok at least we have the kernel of an interesting plan. Sharan, we're waiting for you to say the magic word! Taher Alkhateeb ----- Original Message ----- From: "Adrian Crum" <[hidden email]> To: [hidden email] Sent: Monday, 19 October, 2015 12:48:59 AM Subject: Re: Why A Framework Rewrite Is Necessary That sounds fine to me. Keep in mind that Sharan is spearheading this thing, and I will be effectively uninvolved. But I will offer advice/guidance where I feel it is necessary. Based on Ron's comments, I think it would be best if the Wiki page was moved so others can modify it, or C&P it to a less restrictive area. Adrian Crum Sandglass Software www.sandglass-software.com On 10/18/2015 2:21 PM, Taher Alkhateeb wrote: > Hello Everyone, > > Like Ron I also find the suggestion from David logical and sensible. We can perhaps start with a design for interfaces and XSDs as a first step. Would anyone like to join forces to brainstorm on this issue? Adrian, is that a route that you also prefer? > > Taher Alkhateeb > > ----- Original Message ----- > > From: "Ron Wheeler" <[hidden email]> > To: [hidden email] > Sent: Saturday, 17 October, 2015 10:39:35 PM > Subject: Re: Why A Framework Rewrite Is Necessary > > 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 <[hidden email]> 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 <[hidden email]> wrote: >>>> >>>>>> On 15 Oct 2015, at 07:58, Adrian Crum < >>>>> [hidden email]> 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: [hidden email] >>> skype: ronaldmwheeler >>> phone: 866-970-2435, ext 102 >>> >> > > |
|
Hi All
I went away for the weekend and came back to mega thread of responses here – which is great. And I can see that some really good ideas have come out as feedback already. I think the next step is to see if we can get things moving. I’d like to try and pull together anyone interested in joining an initial brainstorming session to help organise and plan the work. We can do this offline via a group call and then report back on our strategy and plan. I’m not sure how many people we are talking about so I’ll setup a wiki page for people to sign up that are interested in being involved. Then I'll see if can plan a group call later this week or early next week. Thanks Sharan |
|
|
Hi Everyone
I've moved Adrian's Framework Vision page into the wiki https://cwiki.apache.org/confluence/display/OFBIZ/Another+Framework+Vision and I've also created a page where people who are interested in helping can 'sign up' :-). https://cwiki.apache.org/confluence/display/OFBIZ/Potential+Framework+Sub+Project Based on this we can see if we have enough momentum to start things moving. Thanks Sharan |
Re: Why A Framework Rewrite Is Necessary
|
|
Sharan,
Please move the child pages also. The structure I had was: Vision | |_____ Implementation Overview | |___ Implementation Details A | |___ Implementation Details B | . . . Adrian Crum Sandglass Software www.sandglass-software.com On 10/19/2015 8:24 AM, Sharan-F wrote: > Hi Everyone > > I've moved Adrian's Framework Vision page into the wiki > > https://cwiki.apache.org/confluence/display/OFBIZ/Another+Framework+Vision > <https://cwiki.apache.org/confluence/display/OFBIZ/Another+Framework+Vision> > > and I've also created a page where people who are interested in helping can > 'sign up' :-). > > https://cwiki.apache.org/confluence/display/OFBIZ/Potential+Framework+Sub+Project > <https://cwiki.apache.org/confluence/display/OFBIZ/Potential+Framework+Sub+Project> > > Based on this we can see if we have enough momentum to start things moving. > > Thanks > Sharan > > > > -- > View this message in context: http://ofbiz.135035.n4.nabble.com/Why-A-Framework-Rewrite-Is-Necessary-tp4673385p4673586.html > Sent from the OFBiz - Dev mailing list archive at Nabble.com. > |
|
|
In reply to this post by Sharan-F
Hi Sharan,
I do not have access to edit in confluence at the moment. So please sign me up in the page in case I didn't show enough interest :) Taher Alkhateeb ----- Original Message ----- From: "Sharan-F" <[hidden email]> To: [hidden email] Sent: Monday, 19 October, 2015 6:24:05 PM Subject: Re: Why A Framework Rewrite Is Necessary Hi Everyone I've moved Adrian's Framework Vision page into the wiki https://cwiki.apache.org/confluence/display/OFBIZ/Another+Framework+Vision <https://cwiki.apache.org/confluence/display/OFBIZ/Another+Framework+Vision> and I've also created a page where people who are interested in helping can 'sign up' :-). https://cwiki.apache.org/confluence/display/OFBIZ/Potential+Framework+Sub+Project <https://cwiki.apache.org/confluence/display/OFBIZ/Potential+Framework+Sub+Project> Based on this we can see if we have enough momentum to start things moving. Thanks Sharan -- View this message in context: http://ofbiz.135035.n4.nabble.com/Why-A-Framework-Rewrite-Is-Necessary-tp4673385p4673586.html Sent from the OFBiz - Dev mailing list archive at Nabble.com. |
Re: Why A Framework Rewrite Is Necessary
|
|
In reply to this post by Ron Wheeler
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote: >>>> >>>>>> On 15 Oct 2015, at 07:58, Adrian Crum < >>>>> [hidden email]> 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: [hidden email] >>> skype: ronaldmwheeler >>> phone: 866-970-2435, ext 102 >>> >> > > > -- > Ron Wheeler > President > Artifact Software Inc > email: [hidden email] > skype: ronaldmwheeler > phone: 866-970-2435, ext 102 > |
Re: Why A Framework Rewrite Is Necessary
|
|
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote: >>>>> >>>>>>> On 15 Oct 2015, at 07:58, Adrian Crum < >>>>>> [hidden email]> 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: [hidden email] >>>> skype: ronaldmwheeler >>>> phone: 866-970-2435, ext 102 >>>> >> >> -- >> Ron Wheeler >> President >> Artifact Software Inc >> email: [hidden email] >> skype: ronaldmwheeler >> phone: 866-970-2435, ext 102 >> > -- Ron Wheeler President Artifact Software Inc email: [hidden email] skype: ronaldmwheeler phone: 866-970-2435, ext 102 |
Re: Why A Framework Rewrite Is Necessary
|
|
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 <[hidden email] > 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 <[hidden email]> >>> 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 <[hidden email]> >>>>> 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 <[hidden email]> wrote: >>>>>> >>>>>> On 15 Oct 2015, at 07:58, Adrian Crum < >>>>>>>> >>>>>>> [hidden email]> 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: [hidden email] >>>>> skype: ronaldmwheeler >>>>> phone: 866-970-2435, ext 102 >>>>> >>>>> >>> -- >>> Ron Wheeler >>> President >>> Artifact Software Inc >>> email: [hidden email] >>> skype: ronaldmwheeler >>> phone: 866-970-2435, ext 102 >>> >>> >> > > -- > Ron Wheeler > President > Artifact Software Inc > email: [hidden email] > skype: ronaldmwheeler > phone: 866-970-2435, ext 102 > > |
Re: Why A Framework Rewrite Is Necessary
|
|
In reply to this post by Adrian Crum-3
I fixed the linking of the parent to the child pages.
Ron On 19/10/2015 11:39 AM, Adrian Crum wrote: > Sharan, > > Please move the child pages also. The structure I had was: > > Vision > | > |_____ Implementation Overview > | > |___ Implementation Details A > | > |___ Implementation Details B > | > . > . > . > > > Adrian Crum > Sandglass Software > www.sandglass-software.com > > On 10/19/2015 8:24 AM, Sharan-F wrote: >> Hi Everyone >> >> I've moved Adrian's Framework Vision page into the wiki >> >> https://cwiki.apache.org/confluence/display/OFBIZ/Another+Framework+Vision >> >> <https://cwiki.apache.org/confluence/display/OFBIZ/Another+Framework+Vision> >> >> >> and I've also created a page where people who are interested in >> helping can >> 'sign up' :-). >> >> https://cwiki.apache.org/confluence/display/OFBIZ/Potential+Framework+Sub+Project >> >> <https://cwiki.apache.org/confluence/display/OFBIZ/Potential+Framework+Sub+Project> >> >> >> Based on this we can see if we have enough momentum to start things >> moving. >> >> Thanks >> Sharan >> >> >> >> -- >> View this message in context: >> http://ofbiz.135035.n4.nabble.com/Why-A-Framework-Rewrite-Is-Necessary-tp4673385p4673586.html >> Sent from the OFBiz - Dev mailing list archive at Nabble.com. >> > -- Ron Wheeler President Artifact Software Inc email: [hidden email] skype: ronaldmwheeler phone: 866-970-2435, ext 102 |
«
Return to OFBiz - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |