Re: why we should have a 10.04 standalone framework release
Do you think if it was made clear that in packages, org.ofbiz.(module) in the java docs would effectively give you the individual API of that module, would help? http://ci.apache.org/projects/ofbiz/site/javadocs/ or after the change http://ci.apache.org/projects/ofbiz/site/javadocs/10.04/ chris snow sent the following on 9/18/2010 1:39 PM: Making the entity engine available as a standalone module definitely has appeal. For example, the entity engine would sit nicely alongside an ESB such as mule for providing a very flexible and quick to develop persistence adapter. When I talk about the framework being more modular, I am looking far into the future (i.e. I'm dreaming). The first step is to aim for framework/application independence. Someone is going to have to dig around in the framework from time to time. If parts of the framework could be worked on independently of the rest of the framework, it would make those parts much easier to maintain.
Re: why we should have a 10.04 standalone framework release
I'm not sure whether I'm the 1st suggested standalone framework release. But I have given it up. OFBiz was/is built for consultants' satisfaction, it's an ideal agile system for consultants to prove ecommerce is possible and affordable for everyone. Threads in this topic shows a typical discussion between a consultant and a developer. They have different concepts on framework. As a developer, I think framework should only have tomcat, entity engine and service engine. Auth? Tomcat has valve. Perhaps we can change framework to another word, for example, server. Shi Jinghai/Beijing Langhua Ltd. 在 2010-09-18六的 10:56 -0600，David E Jones写道： James, I think that was BJ's point: the OFBiz Entity Engine is NOT an ORM tool, ie there is no attempt to map between an object model and the relational model in the database. We simply use the relational model itself. This reduces redundancy (you don't have to create an object model), and it avoid the often big/annoying problem of impedance mismatch between the two very different ways of modeling and managing data. I never did understand why the lords of Java always felt the need to map EVERYTHING to an object model instead of creating objects that make it easier to work with the natural model of each thing (ie relational databases, services, etc, etc). I guess once you get used to a certain way of doing things it's hard to imagine doing it in any way different. -David On Sep 18, 2010, at 2:38 AM, james_sg wrote: Hi BJ, I treat OFBiz entity engine as an ORM that uses Map for the Object part. The gui modeler is a desktop application (not sure if it is swt based), that helps with the editing of the database definition files, and database schema migration. The gui modeler is not used in the web application, nor does it use JNLP. Cayenne also doesn't generate the html forms from the database. Anyway, I can't think of a strong business case for making entity engine swappable. I thought it is worth mentioning Cayenne since it is similar to OFBiz entity engine. - james BJ Freeman wrote: One of the reason I came to ofbiz was to get away from the bloat of ORM. if I read the modeler right that is swt based Gui which introduces a communication layer back to the server, unlike ofbiz being generated on the fly into html, from the server. BTw I have a Commercial Swt Gui Generator and use it for my legacy apps I converted to ofbiz, as well as the communications layer using JNL. = BJ Freeman Strategic Power Office with Supplier Automation http://www.businessesnetwork.com/automation/viewforum.php?f=52 Specialtymarket.com http://www.specialtymarket.com/ Systems Integrator-- Glad to Assist Chat Y! messenger: bjfr33man james_sg sent the following on 9/18/2010 12:24 AM: Hi all, Apache Cayenne has the closest match to OFBiz Entity Engine. A few points about Cayenne: 1. Cayenne has generic object while OFBiz has Generic Value. 2. Cayene has DerivedDbEntity (depreciating) to OFBiz's View Entity. 3. Cayenne has a gui modeler to map the database. 4. Cayenne supports applications running in cluster. 5. OFBiz requires the developer to explicitly save each generic value. In Cayenne, the developer to save the Generic Object and any associated Generic Objects are implicitly saved. 6. Like OFBiz, the database definition files for Cayenne can be separated and grouped under domains and combined at runtime. 7. Cayenne gui modeler has function to merge database changes, but OFBiz does that automatically. If there is a need or business case to support the swapping of the entity engine, it should support similar ORM and follows the api used in OFBiz. Also note there is a JPA standard for ORM that uses POJO. Regards, James Scott Gray-2 wrote: Hi Chris, Could you explain how you envisage swapping the entity engine with hibernate considering one uses Maps (GenericValue) and the other uses POJOs to represent data? Thanks Scott HotWax Media http://www.hotwaxmedia.com On 18/09/2010, at 1:32 AM, chris snow wrote: I would see entity engine and service engine as separate modules. Each module should have clearly defined api defining how they interact with the outside world. A clearly defined api will facilitate swapping parts. For example, the entity engine could be replaced with a hibernate based engine as long as the api was implemented. (also there would be a module for Birt) On Fri, Sep 17, 2010 at 2:06 PM, BJ Freemanbjf...@free-man.net wrote: to me framework is what has not ability to interact with the real world, like party, but just the tools. so base layer is Entity and service engine. Next layer is Webapp and Widgets. next layer is Webtools next layer is security and common A person should be
Re: why we should have a 10.04 standalone framework release
the discussion about separating the framework came before version 4.0 was David's effort that separated the application and created the framework folder. And yes to garner interest in ofbiz the Ecommerce Application as well as the Engineering were added. If you have read the Data Model books Vol II you will see they are considered secondary application. It took me a year to seperate the frame work in ver 3.0. mostly because of the learning curve and lack of documentation. However it is possible even more so with Trunk. The problem is every is not on the same page as to what would be in the Trunk. That said, if you follow the commits you will see others are gradually cleaning up the dependencies, so there will be a Frame work stand alone at some point. Considering the Scope of ofbiz it seems to be a normal progression for a community based project. Shi Jinghai sent the following on 9/19/2010 6:50 AM: I'm not sure whether I'm the 1st suggested standalone framework release. But I have given it up. OFBiz was/is built for consultants' satisfaction, it's an ideal agile system for consultants to prove ecommerce is possible and affordable for everyone. Threads in this topic shows a typical discussion between a consultant and a developer. They have different concepts on framework. As a developer, I think framework should only have tomcat, entity engine and service engine. Auth? Tomcat has valve. Perhaps we can change framework to another word, for example, server. Shi Jinghai/Beijing Langhua Ltd. 在 2010-09-18六的 10:56 -0600，David E Jones写道： James, I think that was BJ's point: the OFBiz Entity Engine is NOT an ORM tool, ie there is no attempt to map between an object model and the relational model in the database. We simply use the relational model itself. This reduces redundancy (you don't have to create an object model), and it avoid the often big/annoying problem of impedance mismatch between the two very different ways of modeling and managing data. I never did understand why the lords of Java always felt the need to map EVERYTHING to an object model instead of creating objects that make it easier to work with the natural model of each thing (ie relational databases, services, etc, etc). I guess once you get used to a certain way of doing things it's hard to imagine doing it in any way different. -David On Sep 18, 2010, at 2:38 AM, james_sg wrote: Hi BJ, I treat OFBiz entity engine as an ORM that uses Map for the Object part. The gui modeler is a desktop application (not sure if it is swt based), that helps with the editing of the database definition files, and database schema migration. The gui modeler is not used in the web application, nor does it use JNLP. Cayenne also doesn't generate the html forms from the database. Anyway, I can't think of a strong business case for making entity engine swappable. I thought it is worth mentioning Cayenne since it is similar to OFBiz entity engine. - james BJ Freeman wrote: One of the reason I came to ofbiz was to get away from the bloat of ORM. if I read the modeler right that is swt based Gui which introduces a communication layer back to the server, unlike ofbiz being generated on the fly into html, from the server. BTw I have a Commercial Swt Gui Generator and use it for my legacy apps I converted to ofbiz, as well as the communications layer using JNL. = BJ Freeman Strategic Power Office with Supplier Automation http://www.businessesnetwork.com/automation/viewforum.php?f=52 Specialtymarket.comhttp://www.specialtymarket.com/ Systems Integrator-- Glad to Assist Chat Y! messenger: bjfr33man james_sg sent the following on 9/18/2010 12:24 AM: Hi all, Apache Cayenne has the closest match to OFBiz Entity Engine. A few points about Cayenne: 1. Cayenne has generic object while OFBiz has Generic Value. 2. Cayene has DerivedDbEntity (depreciating) to OFBiz's View Entity. 3. Cayenne has a gui modeler to map the database. 4. Cayenne supports applications running in cluster. 5. OFBiz requires the developer to explicitly save each generic value. In Cayenne, the developer to save the Generic Object and any associated Generic Objects are implicitly saved. 6. Like OFBiz, the database definition files for Cayenne can be separated and grouped under domains and combined at runtime. 7. Cayenne gui modeler has function to merge database changes, but OFBiz does that automatically. If there is a need or business case to support the swapping of the entity engine, it should support similar ORM and follows the api used in OFBiz. Also note there is a JPA standard for ORM that uses POJO. Regards, James Scott Gray-2 wrote: Hi Chris, Could you explain how you envisage swapping the entity engine with hibernate considering one uses Maps (GenericValue) and the other uses POJOs to represent data? Thanks Scott HotWax Media http://www.hotwaxmedia.com On 18/09/2010, at 1:32 AM, chris snow wrote: I would
Re: why we should have a 10.04 standalone framework release
Hi Scott, it was just an example. The point I was trying to make is that by making the entity engine a separate module, the implementation doesn't matter as long as the entity engine module fullfilled its api contract. One of the benefits of this modular approach is that it would enable developers or are interested in working on the entity engine could do so without having to first isolate the persistence code from the configuration code. On 18 Sep 2010 06:49, Scott Gray scott.g...@hotwaxmedia.com wrote: Hi Chris, Could you explain how you envisage swapping the entity engine with hibernate considering one uses Maps (GenericValue) and the other uses POJOs to represent data? Thanks Scott HotWax Media http://www.hotwaxmedia.com On 18/09/2010, at 1:32 AM, chris snow wrote: I would see entity engine and service engine as se...
Re: why we should have a 10.04 standalone framework release
Hi all, Apache Cayenne has the closest match to OFBiz Entity Engine. A few points about Cayenne: 1. Cayenne has generic object while OFBiz has Generic Value. 2. Cayene has DerivedDbEntity (depreciating) to OFBiz's View Entity. 3. Cayenne has a gui modeler to map the database. 4. Cayenne supports applications running in cluster. 5. OFBiz requires the developer to explicitly save each generic value. In Cayenne, the developer to save the Generic Object and any associated Generic Objects are implicitly saved. 6. Like OFBiz, the database definition files for Cayenne can be separated and grouped under domains and combined at runtime. 7. Cayenne gui modeler has function to merge database changes, but OFBiz does that automatically. If there is a need or business case to support the swapping of the entity engine, it should support similar ORM and follows the api used in OFBiz. Also note there is a JPA standard for ORM that uses POJO. Regards, James Scott Gray-2 wrote: Hi Chris, Could you explain how you envisage swapping the entity engine with hibernate considering one uses Maps (GenericValue) and the other uses POJOs to represent data? Thanks Scott HotWax Media http://www.hotwaxmedia.com On 18/09/2010, at 1:32 AM, chris snow wrote: I would see entity engine and service engine as separate modules. Each module should have clearly defined api defining how they interact with the outside world. A clearly defined api will facilitate swapping parts. For example, the entity engine could be replaced with a hibernate based engine as long as the api was implemented. (also there would be a module for Birt) On Fri, Sep 17, 2010 at 2:06 PM, BJ Freeman bjf...@free-man.net wrote: to me framework is what has not ability to interact with the real world, like party, but just the tools. so base layer is Entity and service engine. Next layer is Webapp and Widgets. next layer is Webtools next layer is security and common A person should be able to enable those things that they want for their application. chris snow sent the following on 9/17/2010 4:11 AM: If you follow my instructions for 9.04 that will to a large extent give you framework independence. I think 9.04 makes a good basis for looking at modularising parts of ofbiz. For example, I would like to see the entity engine live in its own project. The entity engine from what I remember is currently tightly tied in to performing duties such as reading configuration files. Based on this, I would next focus on giving the entity engine an api for loading it's global configuration and also component configurations. That way, the entity engine could be added to ofbiz as a pure jar file and be configured by some other module (e.g. a configuration service). Isolating parts of the system like the entity engine has a lot of benefits. For example, BJ Freeman has mentioned improvements to the entity engine such as on the fly entity changes. This would be made much easier if the entity engine was not so deeply intertwined with the rest of the ofbiz code. I think github would be the ideal place for hosting this kind of effort. That way non ofbiz commiters could more easily contribute. On Fri, Sep 17, 2010 at 11:49 AM, james_sgsnowme...@hotmail.com wrote: Hi Chris, I believe framework separation is a win-win situation and things will get sorted out when the common agreement is there. I am using 9.04. For non-erp project, I have other favorite framework. -james -- View this message in context: http://ofbiz.135035.n4.nabble.com/why-we-should-have-a-10-04-standalone-framework-release-tp1568563p2544808.html Sent from the OFBiz - User mailing list archive at Nabble.com.
Re: why we should have a 10.04 standalone framework release
Just to add on to point 6. Since the entity in Cayenne can be programmatically construct, it should be possible to read OFBiz's entity files. james_sg wrote: Hi all, Apache Cayenne has the closest match to OFBiz Entity Engine. A few points about Cayenne: 1. Cayenne has generic object while OFBiz has Generic Value. 2. Cayene has DerivedDbEntity (depreciating) to OFBiz's View Entity. 3. Cayenne has a gui modeler to map the database. 4. Cayenne supports applications running in cluster. 5. OFBiz requires the developer to explicitly save each generic value. In Cayenne, the developer to save the Generic Object and any associated Generic Objects are implicitly saved. 6. Like OFBiz, the database definition files for Cayenne can be separated and grouped under domains and combined at runtime. 7. Cayenne gui modeler has function to merge database changes, but OFBiz does that automatically. If there is a need or business case to support the swapping of the entity engine, it should support similar ORM and follows the api used in OFBiz. Also note there is a JPA standard for ORM that uses POJO. Regards, James Scott Gray-2 wrote: Hi Chris, Could you explain how you envisage swapping the entity engine with hibernate considering one uses Maps (GenericValue) and the other uses POJOs to represent data? Thanks Scott HotWax Media http://www.hotwaxmedia.com On 18/09/2010, at 1:32 AM, chris snow wrote: I would see entity engine and service engine as separate modules. Each module should have clearly defined api defining how they interact with the outside world. A clearly defined api will facilitate swapping parts. For example, the entity engine could be replaced with a hibernate based engine as long as the api was implemented. (also there would be a module for Birt) On Fri, Sep 17, 2010 at 2:06 PM, BJ Freeman bjf...@free-man.net wrote: to me framework is what has not ability to interact with the real world, like party, but just the tools. so base layer is Entity and service engine. Next layer is Webapp and Widgets. next layer is Webtools next layer is security and common A person should be able to enable those things that they want for their application. -- View this message in context: http://ofbiz.135035.n4.nabble.com/why-we-should-have-a-10-04-standalone-framework-release-tp1568563p2544818.html Sent from the OFBiz - User mailing list archive at Nabble.com.
Re: why we should have a 10.04 standalone framework release
One of the reason I came to ofbiz was to get away from the bloat of ORM. if I read the modeler right that is swt based Gui which introduces a communication layer back to the server, unlike ofbiz being generated on the fly into html, from the server. BTw I have a Commercial Swt Gui Generator and use it for my legacy apps I converted to ofbiz, as well as the communications layer using JNL. = BJ Freeman Strategic Power Office with Supplier Automation http://www.businessesnetwork.com/automation/viewforum.php?f=52 Specialtymarket.com http://www.specialtymarket.com/ Systems Integrator-- Glad to Assist Chat Y! messenger: bjfr33man james_sg sent the following on 9/18/2010 12:24 AM: Hi all, Apache Cayenne has the closest match to OFBiz Entity Engine. A few points about Cayenne: 1. Cayenne has generic object while OFBiz has Generic Value. 2. Cayene has DerivedDbEntity (depreciating) to OFBiz's View Entity. 3. Cayenne has a gui modeler to map the database. 4. Cayenne supports applications running in cluster. 5. OFBiz requires the developer to explicitly save each generic value. In Cayenne, the developer to save the Generic Object and any associated Generic Objects are implicitly saved. 6. Like OFBiz, the database definition files for Cayenne can be separated and grouped under domains and combined at runtime. 7. Cayenne gui modeler has function to merge database changes, but OFBiz does that automatically. If there is a need or business case to support the swapping of the entity engine, it should support similar ORM and follows the api used in OFBiz. Also note there is a JPA standard for ORM that uses POJO. Regards, James Scott Gray-2 wrote: Hi Chris, Could you explain how you envisage swapping the entity engine with hibernate considering one uses Maps (GenericValue) and the other uses POJOs to represent data? Thanks Scott HotWax Media http://www.hotwaxmedia.com On 18/09/2010, at 1:32 AM, chris snow wrote: I would see entity engine and service engine as separate modules. Each module should have clearly defined api defining how they interact with the outside world. A clearly defined api will facilitate swapping parts. For example, the entity engine could be replaced with a hibernate based engine as long as the api was implemented. (also there would be a module for Birt) On Fri, Sep 17, 2010 at 2:06 PM, BJ Freemanbjf...@free-man.net wrote: to me framework is what has not ability to interact with the real world, like party, but just the tools. so base layer is Entity and service engine. Next layer is Webapp and Widgets. next layer is Webtools next layer is security and common A person should be able to enable those things that they want for their application. chris snow sent the following on 9/17/2010 4:11 AM: If you follow my instructions for 9.04 that will to a large extent give you framework independence. I think 9.04 makes a good basis for looking at modularising parts of ofbiz. For example, I would like to see the entity engine live in its own project. The entity engine from what I remember is currently tightly tied in to performing duties such as reading configuration files. Based on this, I would next focus on giving the entity engine an api for loading it's global configuration and also component configurations. That way, the entity engine could be added to ofbiz as a pure jar file and be configured by some other module (e.g. a configuration service). Isolating parts of the system like the entity engine has a lot of benefits. For example, BJ Freeman has mentioned improvements to the entity engine such as on the fly entity changes. This would be made much easier if the entity engine was not so deeply intertwined with the rest of the ofbiz code. I think github would be the ideal place for hosting this kind of effort. That way non ofbiz commiters could more easily contribute. On Fri, Sep 17, 2010 at 11:49 AM, james_sgsnowme...@hotmail.com wrote: Hi Chris, I believe framework separation is a win-win situation and things will get sorted out when the common agreement is there. I am using 9.04. For non-erp project, I have other favorite framework. -james
Re: why we should have a 10.04 standalone framework release
Hi BJ, I treat OFBiz entity engine as an ORM that uses Map for the Object part. The gui modeler is a desktop application (not sure if it is swt based), that helps with the editing of the database definition files, and database schema migration. The gui modeler is not used in the web application, nor does it use JNLP. Cayenne also doesn't generate the html forms from the database. Anyway, I can't think of a strong business case for making entity engine swappable. I thought it is worth mentioning Cayenne since it is similar to OFBiz entity engine. - james BJ Freeman wrote: One of the reason I came to ofbiz was to get away from the bloat of ORM. if I read the modeler right that is swt based Gui which introduces a communication layer back to the server, unlike ofbiz being generated on the fly into html, from the server. BTw I have a Commercial Swt Gui Generator and use it for my legacy apps I converted to ofbiz, as well as the communications layer using JNL. = BJ Freeman Strategic Power Office with Supplier Automation http://www.businessesnetwork.com/automation/viewforum.php?f=52 Specialtymarket.com http://www.specialtymarket.com/ Systems Integrator-- Glad to Assist Chat Y! messenger: bjfr33man james_sg sent the following on 9/18/2010 12:24 AM: Hi all, Apache Cayenne has the closest match to OFBiz Entity Engine. A few points about Cayenne: 1. Cayenne has generic object while OFBiz has Generic Value. 2. Cayene has DerivedDbEntity (depreciating) to OFBiz's View Entity. 3. Cayenne has a gui modeler to map the database. 4. Cayenne supports applications running in cluster. 5. OFBiz requires the developer to explicitly save each generic value. In Cayenne, the developer to save the Generic Object and any associated Generic Objects are implicitly saved. 6. Like OFBiz, the database definition files for Cayenne can be separated and grouped under domains and combined at runtime. 7. Cayenne gui modeler has function to merge database changes, but OFBiz does that automatically. If there is a need or business case to support the swapping of the entity engine, it should support similar ORM and follows the api used in OFBiz. Also note there is a JPA standard for ORM that uses POJO. Regards, James Scott Gray-2 wrote: Hi Chris, Could you explain how you envisage swapping the entity engine with hibernate considering one uses Maps (GenericValue) and the other uses POJOs to represent data? Thanks Scott HotWax Media http://www.hotwaxmedia.com On 18/09/2010, at 1:32 AM, chris snow wrote: I would see entity engine and service engine as separate modules. Each module should have clearly defined api defining how they interact with the outside world. A clearly defined api will facilitate swapping parts. For example, the entity engine could be replaced with a hibernate based engine as long as the api was implemented. (also there would be a module for Birt) On Fri, Sep 17, 2010 at 2:06 PM, BJ Freemanbjf...@free-man.net wrote: to me framework is what has not ability to interact with the real world, like party, but just the tools. so base layer is Entity and service engine. Next layer is Webapp and Widgets. next layer is Webtools next layer is security and common A person should be able to enable those things that they want for their application. chris snow sent the following on 9/17/2010 4:11 AM: If you follow my instructions for 9.04 that will to a large extent give you framework independence. I think 9.04 makes a good basis for looking at modularising parts of ofbiz. For example, I would like to see the entity engine live in its own project. The entity engine from what I remember is currently tightly tied in to performing duties such as reading configuration files. Based on this, I would next focus on giving the entity engine an api for loading it's global configuration and also component configurations. That way, the entity engine could be added to ofbiz as a pure jar file and be configured by some other module (e.g. a configuration service). Isolating parts of the system like the entity engine has a lot of benefits. For example, BJ Freeman has mentioned improvements to the entity engine such as on the fly entity changes. This would be made much easier if the entity engine was not so deeply intertwined with the rest of the ofbiz code. I think github would be the ideal place for hosting this kind of effort. That way non ofbiz commiters could more easily contribute. On Fri, Sep 17, 2010 at 11:49 AM, james_sgsnowme...@hotmail.com wrote: Hi Chris, I believe framework separation is a win-win situation and things will get sorted out when the common agreement is there. I am using 9.04. For non-erp project, I have other favorite framework. -james -- View this message in context:
Re: why we should have a 10.04 standalone framework release
I'm sorry for pushing this off-track by mentioning hibernate. The important point is that the technologies aren't important. There are many technologies that could be used for the entity engine, and as BJ has pointed out, the ofbiz entity engine is very good. The problem for me is that the entity engine is deeply interwined with the rest of ofbiz. These dependencies need to be managed. Having a more modular ofbiz has advantages for ofbiz as a whole and for each module. On 18 Sep 2010 09:03, BJ Freeman bjf...@free-man.net wrote: One of the reason I came to ofbiz was to get away from the bloat of ORM. if I read the modeler right that is swt based Gui which introduces a communication layer back to the server, unlike ofbiz being generated on the fly into html, from the server. BTw I have a Commercial Swt Gui Generator and use it for my legacy apps I converted to ofbiz, as well as the communications layer using JNL. = BJ Freeman Strategic Power Office with Supplier Automation http://www.businessesnetwork.com/automation/viewf... james_sg sent the following on 9/18/2010 12:24 AM: Hi all, Apache Cayenne has the closest match to OFBiz Entity Engine. A few points abo...
Re: why we should have a 10.04 standalone framework release
Chris I may be dense, but what dependencies do you see from the entity engine to the rest of ofbiz? I agree that from the rest of ofbiz the entity engine is core, and is to me the very reason that ofbiz is great. But from a framework point of view you can strip away the application and specialpurpose and build anything you want on top of the framework. which is why it is called a framework. outside of the base and supporting files in framework, you could probably reemove 50% of the framework and still have the entiy engine work. So is it just a technical thing or is there really a gain in what you are saying? Just trying to get a Grasp on what you goal and scope is. chris snow sent the following on 9/18/2010 1:48 AM: I'm sorry for pushing this off-track by mentioning hibernate. The important point is that the technologies aren't important. There are many technologies that could be used for the entity engine, and as BJ has pointed out, the ofbiz entity engine is very good. The problem for me is that the entity engine is deeply interwined with the rest of ofbiz. These dependencies need to be managed. Having a more modular ofbiz has advantages for ofbiz as a whole and for each module. On 18 Sep 2010 09:03, BJ Freemanbjf...@free-man.net wrote: One of the reason I came to ofbiz was to get away from the bloat of ORM. if I read the modeler right that is swt based Gui which introduces a communication layer back to the server, unlike ofbiz being generated on the fly into html, from the server. BTw I have a Commercial Swt Gui Generator and use it for my legacy apps I converted to ofbiz, as well as the communications layer using JNL. = BJ Freeman Strategic Power Office with Supplier Automation http://www.businessesnetwork.com/automation/viewf... james_sg sent the following on 9/18/2010 12:24 AM: Hi all, Apache Cayenne has the closest match to OFBiz Entity Engine. A few points abo...
Re: why we should have a 10.04 standalone framework release
to give you an example, when first came to ofbiz and had many DB based projects. They already had a data model i had develop over 10 years. so I did not use the applications or data model, that ofbiz had. I induced my data from the db into entity defs and converted the code I had into entity and service engines using the minilanq and java. BJ Freeman sent the following on 9/18/2010 2:02 AM: Chris I may be dense, but what dependencies do you see from the entity engine to the rest of ofbiz? I agree that from the rest of ofbiz the entity engine is core, and is to me the very reason that ofbiz is great. But from a framework point of view you can strip away the application and specialpurpose and build anything you want on top of the framework. which is why it is called a framework. outside of the base and supporting files in framework, you could probably reemove 50% of the framework and still have the entiy engine work. So is it just a technical thing or is there really a gain in what you are saying? Just trying to get a Grasp on what you goal and scope is. chris snow sent the following on 9/18/2010 1:48 AM: I'm sorry for pushing this off-track by mentioning hibernate. The important point is that the technologies aren't important. There are many technologies that could be used for the entity engine, and as BJ has pointed out, the ofbiz entity engine is very good. The problem for me is that the entity engine is deeply interwined with the rest of ofbiz. These dependencies need to be managed. Having a more modular ofbiz has advantages for ofbiz as a whole and for each module. On 18 Sep 2010 09:03, BJ Freemanbjf...@free-man.net wrote: One of the reason I came to ofbiz was to get away from the bloat of ORM. if I read the modeler right that is swt based Gui which introduces a communication layer back to the server, unlike ofbiz being generated on the fly into html, from the server. BTw I have a Commercial Swt Gui Generator and use it for my legacy apps I converted to ofbiz, as well as the communications layer using JNL. = BJ Freeman Strategic Power Office with Supplier Automation http://www.businessesnetwork.com/automation/viewf... james_sg sent the following on 9/18/2010 12:24 AM: Hi all, Apache Cayenne has the closest match to OFBiz Entity Engine. A few points abo...
Re: why we should have a 10.04 standalone framework release
Hi BJ, there are parts of ofbiz that could be 'easily' used outside of ofbiz if they weren't all part of the same code base. The Entity Engine example is one part that could become a library. Other parts include the datatype coverters and temporal expressions. At the moment if I want to use these parts of ofbiz in external applications, I have to manually extract them from the ofbiz code base. The framework would then be an assembly of libraries. By splitting ofbiz up, each library (entity engine, converters, temporal expressions, etc) could be developed independently of the rest of the ofbiz code. Do you want me do list the advantages of this approach? On Sat, Sep 18, 2010 at 10:02 AM, BJ Freeman bjf...@free-man.net wrote: Chris I may be dense, but what dependencies do you see from the entity engine to the rest of ofbiz? I agree that from the rest of ofbiz the entity engine is core, and is to me the very reason that ofbiz is great. But from a framework point of view you can strip away the application and specialpurpose and build anything you want on top of the framework. which is why it is called a framework. outside of the base and supporting files in framework, you could probably reemove 50% of the framework and still have the entiy engine work. So is it just a technical thing or is there really a gain in what you are saying? Just trying to get a Grasp on what you goal and scope is. chris snow sent the following on 9/18/2010 1:48 AM: I'm sorry for pushing this off-track by mentioning hibernate. The important point is that the technologies aren't important. There are many technologies that could be used for the entity engine, and as BJ has pointed out, the ofbiz entity engine is very good. The problem for me is that the entity engine is deeply interwined with the rest of ofbiz. These dependencies need to be managed. Having a more modular ofbiz has advantages for ofbiz as a whole and for each module. On 18 Sep 2010 09:03, BJ Freemanbjf...@free-man.net wrote: One of the reason I came to ofbiz was to get away from the bloat of ORM. if I read the modeler right that is swt based Gui which introduces a communication layer back to the server, unlike ofbiz being generated on the fly into html, from the server. BTw I have a Commercial Swt Gui Generator and use it for my legacy apps I converted to ofbiz, as well as the communications layer using JNL. = BJ Freeman Strategic Power Office with Supplier Automation http://www.businessesnetwork.com/automation/viewf... james_sg sent the following on 9/18/2010 12:24 AM: Hi all, Apache Cayenne has the closest match to OFBiz Entity Engine. A few points abo...
Re: why we should have a 10.04 standalone framework release
Thanks for the taking the time to explain. So you planning a seperate project? I don't see the business need for distribution in this environment of just the Jars, for the framework. I could see them in another environment that is not directly related to this project(svn). chris snow sent the following on 9/18/2010 2:42 AM: Hi BJ, there are parts of ofbiz that could be 'easily' used outside of ofbiz if they weren't all part of the same code base. The Entity Engine example is one part that could become a library. Other parts include the datatype coverters and temporal expressions. At the moment if I want to use these parts of ofbiz in external applications, I have to manually extract them from the ofbiz code base. The framework would then be an assembly of libraries. By splitting ofbiz up, each library (entity engine, converters, temporal expressions, etc) could be developed independently of the rest of the ofbiz code. Do you want me do list the advantages of this approach? On Sat, Sep 18, 2010 at 10:02 AM, BJ Freemanbjf...@free-man.net wrote: Chris I may be dense, but what dependencies do you see from the entity engine to the rest of ofbiz? I agree that from the rest of ofbiz the entity engine is core, and is to me the very reason that ofbiz is great. But from a framework point of view you can strip away the application and specialpurpose and build anything you want on top of the framework. which is why it is called a framework. outside of the base and supporting files in framework, you could probably reemove 50% of the framework and still have the entiy engine work. So is it just a technical thing or is there really a gain in what you are saying? Just trying to get a Grasp on what you goal and scope is. chris snow sent the following on 9/18/2010 1:48 AM: I'm sorry for pushing this off-track by mentioning hibernate. The important point is that the technologies aren't important. There are many technologies that could be used for the entity engine, and as BJ has pointed out, the ofbiz entity engine is very good. The problem for me is that the entity engine is deeply interwined with the rest of ofbiz. These dependencies need to be managed. Having a more modular ofbiz has advantages for ofbiz as a whole and for each module. On 18 Sep 2010 09:03, BJ Freemanbjf...@free-man.netwrote: One of the reason I came to ofbiz was to get away from the bloat of ORM. if I read the modeler right that is swt based Gui which introduces a communication layer back to the server, unlike ofbiz being generated on the fly into html, from the server. BTw I have a Commercial Swt Gui Generator and use it for my legacy apps I converted to ofbiz, as well as the communications layer using JNL. = BJ Freeman Strategic Power Office with Supplier Automation http://www.businessesnetwork.com/automation/viewf... james_sg sent the following on 9/18/2010 12:24 AM: Hi all, Apache Cayenne has the closest match to OFBiz Entity Engine. A few points abo...
Re: why we should have a 10.04 standalone framework release
James, I think that was BJ's point: the OFBiz Entity Engine is NOT an ORM tool, ie there is no attempt to map between an object model and the relational model in the database. We simply use the relational model itself. This reduces redundancy (you don't have to create an object model), and it avoid the often big/annoying problem of impedance mismatch between the two very different ways of modeling and managing data. I never did understand why the lords of Java always felt the need to map EVERYTHING to an object model instead of creating objects that make it easier to work with the natural model of each thing (ie relational databases, services, etc, etc). I guess once you get used to a certain way of doing things it's hard to imagine doing it in any way different. -David On Sep 18, 2010, at 2:38 AM, james_sg wrote: Hi BJ, I treat OFBiz entity engine as an ORM that uses Map for the Object part. The gui modeler is a desktop application (not sure if it is swt based), that helps with the editing of the database definition files, and database schema migration. The gui modeler is not used in the web application, nor does it use JNLP. Cayenne also doesn't generate the html forms from the database. Anyway, I can't think of a strong business case for making entity engine swappable. I thought it is worth mentioning Cayenne since it is similar to OFBiz entity engine. - james BJ Freeman wrote: One of the reason I came to ofbiz was to get away from the bloat of ORM. if I read the modeler right that is swt based Gui which introduces a communication layer back to the server, unlike ofbiz being generated on the fly into html, from the server. BTw I have a Commercial Swt Gui Generator and use it for my legacy apps I converted to ofbiz, as well as the communications layer using JNL. = BJ Freeman Strategic Power Office with Supplier Automation http://www.businessesnetwork.com/automation/viewforum.php?f=52 Specialtymarket.com http://www.specialtymarket.com/ Systems Integrator-- Glad to Assist Chat Y! messenger: bjfr33man james_sg sent the following on 9/18/2010 12:24 AM: Hi all, Apache Cayenne has the closest match to OFBiz Entity Engine. A few points about Cayenne: 1. Cayenne has generic object while OFBiz has Generic Value. 2. Cayene has DerivedDbEntity (depreciating) to OFBiz's View Entity. 3. Cayenne has a gui modeler to map the database. 4. Cayenne supports applications running in cluster. 5. OFBiz requires the developer to explicitly save each generic value. In Cayenne, the developer to save the Generic Object and any associated Generic Objects are implicitly saved. 6. Like OFBiz, the database definition files for Cayenne can be separated and grouped under domains and combined at runtime. 7. Cayenne gui modeler has function to merge database changes, but OFBiz does that automatically. If there is a need or business case to support the swapping of the entity engine, it should support similar ORM and follows the api used in OFBiz. Also note there is a JPA standard for ORM that uses POJO. Regards, James Scott Gray-2 wrote: Hi Chris, Could you explain how you envisage swapping the entity engine with hibernate considering one uses Maps (GenericValue) and the other uses POJOs to represent data? Thanks Scott HotWax Media http://www.hotwaxmedia.com On 18/09/2010, at 1:32 AM, chris snow wrote: I would see entity engine and service engine as separate modules. Each module should have clearly defined api defining how they interact with the outside world. A clearly defined api will facilitate swapping parts. For example, the entity engine could be replaced with a hibernate based engine as long as the api was implemented. (also there would be a module for Birt) On Fri, Sep 17, 2010 at 2:06 PM, BJ Freemanbjf...@free-man.net wrote: to me framework is what has not ability to interact with the real world, like party, but just the tools. so base layer is Entity and service engine. Next layer is Webapp and Widgets. next layer is Webtools next layer is security and common A person should be able to enable those things that they want for their application. chris snow sent the following on 9/17/2010 4:11 AM: If you follow my instructions for 9.04 that will to a large extent give you framework independence. I think 9.04 makes a good basis for looking at modularising parts of ofbiz. For example, I would like to see the entity engine live in its own project. The entity engine from what I remember is currently tightly tied in to performing duties such as reading configuration files. Based on this, I would next focus on giving the entity engine an api for loading it's global configuration and also component configurations. That way, the entity engine could be added to ofbiz as a pure jar file and be configured by some other module
Re: why we should have a 10.04 standalone framework release
That's my idea also. Any office automation system needs everything is now in the framework folder (entity engine, service engine, job scheduling, screen widgets, portals, localization, themes, webslinger!, etc.) plus IMO a basic party management system to allow users to login and interact with the system itself. Users should be able to read some help or some sort of documentation in the system they log in even before using any specific application and this is why a basic content application should be also part of the OFBiz core system. Any user that logs in a system should be emailed back if they forgot the password. Or they should be able to communicate with the system admin to ask hey! When my specific application will be available in the system? This is why a basic communication mechanism should be also part of the OFBiz core. I use the OFBiz core term because I see that any time we speak about the framework-only distribution we never agree. May be this vision could find more people on the same page. (Or may be no one) I have not worked with any other framework than OFBiz so may be someone could say: hey! But what you call OFBiz core is nothing more than what you get using XXYYZZ. If this is could you please give me any pointer? Thank you, Bruno 2010/9/18 David E Jones d...@me.com When was the last time you worked on a project where you only needed a tool for persistence and didn't need tools for anything else? On the other hand, if you really LIKE to roll your own framework for each project, and based on tools that aren't necessarily meant to work together, then the approach you mentioned below is a great way to enjoy endless evenings and weekends. On the other hand, if you want to focus on developing things needed for applications instead of digging around in a framework for weeks and deciding how to do every little thing, then it's nice to have a complete framework to start with so you can efficiently work on the stuff that is important to your client. -David On Sep 18, 2010, at 2:48 AM, chris snow wrote: I'm sorry for pushing this off-track by mentioning hibernate. The important point is that the technologies aren't important. There are many technologies that could be used for the entity engine, and as BJ has pointed out, the ofbiz entity engine is very good. The problem for me is that the entity engine is deeply interwined with the rest of ofbiz. These dependencies need to be managed. Having a more modular ofbiz has advantages for ofbiz as a whole and for each module. On 18 Sep 2010 09:03, BJ Freeman bjf...@free-man.net wrote: One of the reason I came to ofbiz was to get away from the bloat of ORM. if I read the modeler right that is swt based Gui which introduces a communication layer back to the server, unlike ofbiz being generated on the fly into html, from the server. BTw I have a Commercial Swt Gui Generator and use it for my legacy apps I converted to ofbiz, as well as the communications layer using JNL. = BJ Freeman Strategic Power Office with Supplier Automation http://www.businessesnetwork.com/automation/viewf... james_sg sent the following on 9/18/2010 12:24 AM: Hi all, Apache Cayenne has the closest match to OFBiz Entity Engine. A few points abo...
Re: why we should have a 10.04 standalone framework release
Making the entity engine available as a standalone module definitely has appeal. For example, the entity engine would sit nicely alongside an ESB such as mule for providing a very flexible and quick to develop persistence adapter. When I talk about the framework being more modular, I am looking far into the future (i.e. I'm dreaming). The first step is to aim for framework/application independence. Someone is going to have to dig around in the framework from time to time. If parts of the framework could be worked on independently of the rest of the framework, it would make those parts much easier to maintain. -- View this message in context: http://ofbiz.135035.n4.nabble.com/why-we-should-have-a-10-04-standalone-framework-release-tp1568563p2545511.html Sent from the OFBiz - User mailing list archive at Nabble.com.
Re: why we should have a 10.04 standalone framework release
On Sat, 2010-09-18 at 10:42 +0100, chris snow wrote: Hi BJ, there are parts of ofbiz that could be 'easily' used outside of ofbiz if they weren't all part of the same code base. The Entity Engine example is one part that could become a library. Other parts include the datatype coverters and temporal expressions. At the moment if I want to use these parts of ofbiz in external applications, I have to manually extract them from the ofbiz code base. The framework would then be an assembly of libraries. By splitting ofbiz up, each library (entity engine, converters, temporal expressions, etc) could be developed independently of the rest of the ofbiz code. Do you want me do list the advantages of this approach? Nope. But it might be nice if: 1) Everyone stopped top posting so that ofbiz newbies could more easily follow the chronology of discussion threads. 2) You listed the disadvantages of your approach. Thank you and have a nice day;) -- Ken Gunderson kgund...@teamcool.net
Re: why we should have a 10.04 standalone framework release
Might I suggest Setup method. https://issues.apache.org/jira/browse/OFBIZ-635 have a group System Setup Bruno Busco sent the following on 9/18/2010 1:11 PM: That's my idea also. Any office automation system needs everything is now in the framework folder (entity engine, service engine, job scheduling, screen widgets, portals, localization, themes, webslinger!, etc.) plus IMO a basic party management system to allow users to login and interact with the system itself. Users should be able to read some help or some sort of documentation in the system they log in even before using any specific application and this is why a basic content application should be also part of the OFBiz core system. Any user that logs in a system should be emailed back if they forgot the password. Or they should be able to communicate with the system admin to ask hey! When my specific application will be available in the system? This is why a basic communication mechanism should be also part of the OFBiz core. I use the OFBiz core term because I see that any time we speak about the framework-only distribution we never agree. May be this vision could find more people on the same page. (Or may be no one) I have not worked with any other framework than OFBiz so may be someone could say: hey! But what you call OFBiz core is nothing more than what you get using XXYYZZ. If this is could you please give me any pointer? Thank you, Bruno 2010/9/18 David E Jonesd...@me.com When was the last time you worked on a project where you only needed a tool for persistence and didn't need tools for anything else? On the other hand, if you really LIKE to roll your own framework for each project, and based on tools that aren't necessarily meant to work together, then the approach you mentioned below is a great way to enjoy endless evenings and weekends. On the other hand, if you want to focus on developing things needed for applications instead of digging around in a framework for weeks and deciding how to do every little thing, then it's nice to have a complete framework to start with so you can efficiently work on the stuff that is important to your client. -David On Sep 18, 2010, at 2:48 AM, chris snow wrote: I'm sorry for pushing this off-track by mentioning hibernate. The important point is that the technologies aren't important. There are many technologies that could be used for the entity engine, and as BJ has pointed out, the ofbiz entity engine is very good. The problem for me is that the entity engine is deeply interwined with the rest of ofbiz. These dependencies need to be managed. Having a more modular ofbiz has advantages for ofbiz as a whole and for each module. On 18 Sep 2010 09:03, BJ Freemanbjf...@free-man.net wrote: One of the reason I came to ofbiz was to get away from the bloat of ORM. if I read the modeler right that is swt based Gui which introduces a communication layer back to the server, unlike ofbiz being generated on the fly into html, from the server. BTw I have a Commercial Swt Gui Generator and use it for my legacy apps I converted to ofbiz, as well as the communications layer using JNL. = BJ Freeman Strategic Power Office with Supplier Automation http://www.businessesnetwork.com/automation/viewf... james_sg sent the following on 9/18/2010 12:24 AM: Hi all, Apache Cayenne has the closest match to OFBiz Entity Engine. A few points abo...
Re: why we should have a 10.04 standalone framework release
Hi David, Thanks for the correction. - james David E Jones-4 wrote: James, I think that was BJ's point: the OFBiz Entity Engine is NOT an ORM tool, ie there is no attempt to map between an object model and the relational model in the database. We simply use the relational model itself. This reduces redundancy (you don't have to create an object model), and it avoid the often big/annoying problem of impedance mismatch between the two very different ways of modeling and managing data. I never did understand why the lords of Java always felt the need to map EVERYTHING to an object model instead of creating objects that make it easier to work with the natural model of each thing (ie relational databases, services, etc, etc). I guess once you get used to a certain way of doing things it's hard to imagine doing it in any way different. -David On Sep 18, 2010, at 2:38 AM, james_sg wrote: Hi BJ, I treat OFBiz entity engine as an ORM that uses Map for the Object part. The gui modeler is a desktop application (not sure if it is swt based), that helps with the editing of the database definition files, and database schema migration. The gui modeler is not used in the web application, nor does it use JNLP. Cayenne also doesn't generate the html forms from the database. Anyway, I can't think of a strong business case for making entity engine swappable. I thought it is worth mentioning Cayenne since it is similar to OFBiz entity engine. - james BJ Freeman wrote: One of the reason I came to ofbiz was to get away from the bloat of ORM. if I read the modeler right that is swt based Gui which introduces a communication layer back to the server, unlike ofbiz being generated on the fly into html, from the server. BTw I have a Commercial Swt Gui Generator and use it for my legacy apps I converted to ofbiz, as well as the communications layer using JNL. = BJ Freeman Strategic Power Office with Supplier Automation http://www.businessesnetwork.com/automation/viewforum.php?f=52 Specialtymarket.com http://www.specialtymarket.com/ Systems Integrator-- Glad to Assist Chat Y! messenger: bjfr33man james_sg sent the following on 9/18/2010 12:24 AM: Hi all, Apache Cayenne has the closest match to OFBiz Entity Engine. A few points about Cayenne: 1. Cayenne has generic object while OFBiz has Generic Value. 2. Cayene has DerivedDbEntity (depreciating) to OFBiz's View Entity. 3. Cayenne has a gui modeler to map the database. 4. Cayenne supports applications running in cluster. 5. OFBiz requires the developer to explicitly save each generic value. In Cayenne, the developer to save the Generic Object and any associated Generic Objects are implicitly saved. 6. Like OFBiz, the database definition files for Cayenne can be separated and grouped under domains and combined at runtime. 7. Cayenne gui modeler has function to merge database changes, but OFBiz does that automatically. If there is a need or business case to support the swapping of the entity engine, it should support similar ORM and follows the api used in OFBiz. Also note there is a JPA standard for ORM that uses POJO. Regards, James Scott Gray-2 wrote: Hi Chris, Could you explain how you envisage swapping the entity engine with hibernate considering one uses Maps (GenericValue) and the other uses POJOs to represent data? Thanks Scott HotWax Media http://www.hotwaxmedia.com On 18/09/2010, at 1:32 AM, chris snow wrote: I would see entity engine and service engine as separate modules. Each module should have clearly defined api defining how they interact with the outside world. A clearly defined api will facilitate swapping parts. For example, the entity engine could be replaced with a hibernate based engine as long as the api was implemented. (also there would be a module for Birt) On Fri, Sep 17, 2010 at 2:06 PM, BJ Freemanbjf...@free-man.net wrote: to me framework is what has not ability to interact with the real world, like party, but just the tools. so base layer is Entity and service engine. Next layer is Webapp and Widgets. next layer is Webtools next layer is security and common A person should be able to enable those things that they want for their application. chris snow sent the following on 9/17/2010 4:11 AM: If you follow my instructions for 9.04 that will to a large extent give you framework independence. I think 9.04 makes a good basis for looking at modularising parts of ofbiz. For example, I would like to see the entity engine live in its own project. The entity engine from what I remember is currently tightly tied in to performing duties such as reading configuration files. Based on this, I would next focus on giving the entity engine an api for loading it's global configuration and also component configurations. That way, the
Re: why we should have a 10.04 standalone framework release
Hi James, I spent a lot of time looking at this and came to the conclusion that in 10.04 the dependencies between framework and applications became too intertwined to make a separate 10.04 framework. Here are some of the pages I put together documenting my steps: https://cwiki.apache.org/confluence/x/eIOJ https://cwiki.apache.org/confluence/x/nYTW I haven't used ofbiz for a while, however recently I started using ofbiz 9.04 and I may take another look at using 9.04 as the basis for some development effort to make ofbiz more modular (e.g. split the project up maven style and make the entity engine a separate project that can be used independently of ofbiz). There was also a interesting work by Raj to use OSGi to make the dependencies in ofbiz more explicit and controllable - https://sourceforge.net/projects/ofbiz-osgi/ David's new project is very interesting, because he will be 'vetting' all code that gets committed, which doesn't happen with the ofbiz svn repository. Cheers, Chris On Fri, Sep 17, 2010 at 3:24 AM, james_sg snowme...@hotmail.com wrote: Does anyone know the status of this? --james BJ Freeman wrote: I am for standalone framework. David has been working on that project for a while, if I remember correctly. #2 bothers me though. The design of ofbiz was that the entity was the controlling factor for creating DB and UI. I was one of the major reasons I came to ofbiz. That said, any work that wants to be done on UI integration that makes ofbiz look classy, I think should be the focus. A lot of work has been done in that area. But integrating other UI interfaces that keep the design idea of the entity being to controlling focus is what I would like to see. I don't see ofbiz being object oriented in the normal sense. I see the effort for the help files and a easily understood UI from the user point of view being the main factors in promoting ofbiz. Chris Snow sent the following on 2/24/2010 10:47 PM: Here are some benefits of a 10.04 standalone framework release: 1) Standalone framework users would be a form of quality control helping to ensure more incorrect dependencies don't find there way into ofbiz. 2) we would be able to promote the framework in its own right thus competing with OpenERP's OpenObject platform 3) a much larger potential user base than ecommerce or erp users. Any more that I have missed? -- View this message in context: http://ofbiz.135035.n4.nabble.com/why-we-should-have-a-10-04-standalone-framework-release-tp1568563p2543258.html Sent from the OFBiz - User mailing list archive at Nabble.com.
Re: why we should have a 10.04 standalone framework release
We (Erwan and me mostly) did some work to remove existing dependencies from the Example component there are still some but very easy to remove Also note this page https://cwiki.apache.org/confluence/display/OFBADMIN/Component+and+Component+Set+Dependencies I think we should group all pages (with Chris's) under a main page in Wiki (though I already tried to link them with links from each page to the other, but it's not good enough. It's like when you relate issues in Jira, it helps but is not clearly seen by everybody) And have a hat Jira issue as well because of https://issues.apache.org/jira/browse/OFBIZ-1867 existing also. My 2cts Jacques From: Bruno Busco bruno.bu...@gmail.com Hi James, I did write a wiki page to define how the framework only distribution should be shaped. Following that there was some mail thread in which we discussed about. Some of us was not on the same page but we did not agree on something different that could be written updating the wiki page. You can find the wiki page here: https://cwiki.apache.org/confluence/display/OFBIZ/Framework-only+distribution Fill free to express your opinion and help on that. A contribute that will gine IMO a great help on framework independence is also: https://issues.apache.org/jira/browse/OFBIZ-3373 Scott is working on that and I am looking forward to it. -Bruno 2010/9/17 james_sg snowme...@hotmail.com I think a common agreement is needed among developers on whether OFBiz should have a standalone framework. If a common agreement is reached, then we need to have a common understanding on how things should be done, so that people plays by the rule. Which function to move into the standalone framework can be discussed later. The one with the least dependence can go in first. At least, things are moving... My 2 cents. --james BJ Freeman wrote: the only one that seems active in this is Bruno one such effort. https://issues.apache.org/jira/browse/OFBIZ-3894 james_sg sent the following on 9/16/2010 7:24 PM: Does anyone know the status of this? --james BJ Freeman wrote: I am for standalone framework. David has been working on that project for a while, if I remember correctly. #2 bothers me though. The design of ofbiz was that the entity was the controlling factor for creating DB and UI. I was one of the major reasons I came to ofbiz. That said, any work that wants to be done on UI integration that makes ofbiz look classy, I think should be the focus. A lot of work has been done in that area. But integrating other UI interfaces that keep the design idea of the entity being to controlling focus is what I would like to see. I don't see ofbiz being object oriented in the normal sense. I see the effort for the help files and a easily understood UI from the user point of view being the main factors in promoting ofbiz. Chris Snow sent the following on 2/24/2010 10:47 PM: Here are some benefits of a 10.04 standalone framework release: 1) Standalone framework users would be a form of quality control helping to ensure more incorrect dependencies don't find there way into ofbiz. 2) we would be able to promote the framework in its own right thus competing with OpenERP's OpenObject platform 3) a much larger potential user base than ecommerce or erp users. Any more that I have missed? -- View this message in context: http://ofbiz.135035.n4.nabble.com/why-we-should-have-a-10-04-standalone-framework-release-tp1568563p2543310.html Sent from the OFBiz - User mailing list archive at Nabble.com.
Re: why we should have a 10.04 standalone framework release
Hi Bruno, My opinions as below: For now, I will call the standalone framework as framework project and the rest of the components as applications project. 1. As the current framework embeds servlet container like Tomcat and Jetty, codes related to servlet containers stay with the standalone framework. 2. Webtools and Example should be in the framework project. 2. Party application shouldn't be in framework. But it can be decoupled from the rest of the applications. 3. It is also alrite for Party application to reference other applications like Order, but a. links to other application, should be disabled in realtime if the other application component is not loaded. b. the framework should inject scripts (like css and js) into the header (similar to what wicket and click framework is doing) if screens from other application is used. Likewise, if screens from other application are called without the applications being loaded, the framework should provide some useful screen messages when the screen is loaded. 4. The application project should contain the compiled framework without its source code. In the long run, it should be easy to simply drop the framework into the applications project, or the applications project into the framework. 5. Themes can go with the framework with a default theme, and the rest as adds-on. 6. The framework project can have more frequent releases than the application project, while keeping the goals for the framework project in alignment with the applications project as what currently is. - james Bruno Busco wrote: Hi James, I did write a wiki page to define how the framework only distribution should be shaped. Following that there was some mail thread in which we discussed about. Some of us was not on the same page but we did not agree on something different that could be written updating the wiki page. You can find the wiki page here: https://cwiki.apache.org/confluence/display/OFBIZ/Framework-only+distribution Fill free to express your opinion and help on that. A contribute that will gine IMO a great help on framework independence is also: https://issues.apache.org/jira/browse/OFBIZ-3373 Scott is working on that and I am looking forward to it. -Bruno -- View this message in context: http://ofbiz.135035.n4.nabble.com/why-we-should-have-a-10-04-standalone-framework-release-tp1568563p2543514.html Sent from the OFBiz - User mailing list archive at Nabble.com.
Re: why we should have a 10.04 standalone framework release
Hi Chris, I believe framework separation is a win-win situation and things will get sorted out when the common agreement is there. I am using 9.04. For non-erp project, I have other favorite framework. -james chris snow wrote: Hi James, I spent a lot of time looking at this and came to the conclusion that in 10.04 the dependencies between framework and applications became too intertwined to make a separate 10.04 framework. Here are some of the pages I put together documenting my steps: https://cwiki.apache.org/confluence/x/eIOJ https://cwiki.apache.org/confluence/x/nYTW I haven't used ofbiz for a while, however recently I started using ofbiz 9.04 and I may take another look at using 9.04 as the basis for some development effort to make ofbiz more modular (e.g. split the project up maven style and make the entity engine a separate project that can be used independently of ofbiz). There was also a interesting work by Raj to use OSGi to make the dependencies in ofbiz more explicit and controllable - https://sourceforge.net/projects/ofbiz-osgi/ David's new project is very interesting, because he will be 'vetting' all code that gets committed, which doesn't happen with the ofbiz svn repository. Cheers, Chris On Fri, Sep 17, 2010 at 3:24 AM, james_sg snowme...@hotmail.com wrote: Does anyone know the status of this? --james BJ Freeman wrote: I am for standalone framework. David has been working on that project for a while, if I remember correctly. #2 bothers me though. The design of ofbiz was that the entity was the controlling factor for creating DB and UI. I was one of the major reasons I came to ofbiz. That said, any work that wants to be done on UI integration that makes ofbiz look classy, I think should be the focus. A lot of work has been done in that area. But integrating other UI interfaces that keep the design idea of the entity being to controlling focus is what I would like to see. I don't see ofbiz being object oriented in the normal sense. I see the effort for the help files and a easily understood UI from the user point of view being the main factors in promoting ofbiz. Chris Snow sent the following on 2/24/2010 10:47 PM: Here are some benefits of a 10.04 standalone framework release: 1) Standalone framework users would be a form of quality control helping to ensure more incorrect dependencies don't find there way into ofbiz. 2) we would be able to promote the framework in its own right thus competing with OpenERP's OpenObject platform 3) a much larger potential user base than ecommerce or erp users. Any more that I have missed? -- View this message in context: http://ofbiz.135035.n4.nabble.com/why-we-should-have-a-10-04-standalone-framework-release-tp1568563p2543258.html Sent from the OFBiz - User mailing list archive at Nabble.com. -- View this message in context: http://ofbiz.135035.n4.nabble.com/why-we-should-have-a-10-04-standalone-framework-release-tp1568563p2543697.html Sent from the OFBiz - User mailing list archive at Nabble.com.
Re: why we should have a 10.04 standalone framework release
If you follow my instructions for 9.04 that will to a large extent give you framework independence. I think 9.04 makes a good basis for looking at modularising parts of ofbiz. For example, I would like to see the entity engine live in its own project. The entity engine from what I remember is currently tightly tied in to performing duties such as reading configuration files. Based on this, I would next focus on giving the entity engine an api for loading it's global configuration and also component configurations. That way, the entity engine could be added to ofbiz as a pure jar file and be configured by some other module (e.g. a configuration service). Isolating parts of the system like the entity engine has a lot of benefits. For example, BJ Freeman has mentioned improvements to the entity engine such as on the fly entity changes. This would be made much easier if the entity engine was not so deeply intertwined with the rest of the ofbiz code. I think github would be the ideal place for hosting this kind of effort. That way non ofbiz commiters could more easily contribute. On Fri, Sep 17, 2010 at 11:49 AM, james_sg snowme...@hotmail.com wrote: Hi Chris, I believe framework separation is a win-win situation and things will get sorted out when the common agreement is there. I am using 9.04. For non-erp project, I have other favorite framework. -james chris snow wrote: Hi James, I spent a lot of time looking at this and came to the conclusion that in 10.04 the dependencies between framework and applications became too intertwined to make a separate 10.04 framework. Here are some of the pages I put together documenting my steps: https://cwiki.apache.org/confluence/x/eIOJ https://cwiki.apache.org/confluence/x/nYTW I haven't used ofbiz for a while, however recently I started using ofbiz 9.04 and I may take another look at using 9.04 as the basis for some development effort to make ofbiz more modular (e.g. split the project up maven style and make the entity engine a separate project that can be used independently of ofbiz). There was also a interesting work by Raj to use OSGi to make the dependencies in ofbiz more explicit and controllable - https://sourceforge.net/projects/ofbiz-osgi/ David's new project is very interesting, because he will be 'vetting' all code that gets committed, which doesn't happen with the ofbiz svn repository. Cheers, Chris On Fri, Sep 17, 2010 at 3:24 AM, james_sg snowme...@hotmail.com wrote: Does anyone know the status of this? --james BJ Freeman wrote: I am for standalone framework. David has been working on that project for a while, if I remember correctly. #2 bothers me though. The design of ofbiz was that the entity was the controlling factor for creating DB and UI. I was one of the major reasons I came to ofbiz. That said, any work that wants to be done on UI integration that makes ofbiz look classy, I think should be the focus. A lot of work has been done in that area. But integrating other UI interfaces that keep the design idea of the entity being to controlling focus is what I would like to see. I don't see ofbiz being object oriented in the normal sense. I see the effort for the help files and a easily understood UI from the user point of view being the main factors in promoting ofbiz. Chris Snow sent the following on 2/24/2010 10:47 PM: Here are some benefits of a 10.04 standalone framework release: 1) Standalone framework users would be a form of quality control helping to ensure more incorrect dependencies don't find there way into ofbiz. 2) we would be able to promote the framework in its own right thus competing with OpenERP's OpenObject platform 3) a much larger potential user base than ecommerce or erp users. Any more that I have missed? -- View this message in context: http://ofbiz.135035.n4.nabble.com/why-we-should-have-a-10-04-standalone-framework-release-tp1568563p2543258.html Sent from the OFBiz - User mailing list archive at Nabble.com. -- View this message in context: http://ofbiz.135035.n4.nabble.com/why-we-should-have-a-10-04-standalone-framework-release-tp1568563p2543697.html Sent from the OFBiz - User mailing list archive at Nabble.com.
Re: why we should have a 10.04 standalone framework release
to me framework is what has not ability to interact with the real world, like party, but just the tools. so base layer is Entity and service engine. Next layer is Webapp and Widgets. next layer is Webtools next layer is security and common A person should be able to enable those things that they want for their application. chris snow sent the following on 9/17/2010 4:11 AM: If you follow my instructions for 9.04 that will to a large extent give you framework independence. I think 9.04 makes a good basis for looking at modularising parts of ofbiz. For example, I would like to see the entity engine live in its own project. The entity engine from what I remember is currently tightly tied in to performing duties such as reading configuration files. Based on this, I would next focus on giving the entity engine an api for loading it's global configuration and also component configurations. That way, the entity engine could be added to ofbiz as a pure jar file and be configured by some other module (e.g. a configuration service). Isolating parts of the system like the entity engine has a lot of benefits. For example, BJ Freeman has mentioned improvements to the entity engine such as on the fly entity changes. This would be made much easier if the entity engine was not so deeply intertwined with the rest of the ofbiz code. I think github would be the ideal place for hosting this kind of effort. That way non ofbiz commiters could more easily contribute. On Fri, Sep 17, 2010 at 11:49 AM, james_sgsnowme...@hotmail.com wrote: Hi Chris, I believe framework separation is a win-win situation and things will get sorted out when the common agreement is there. I am using 9.04. For non-erp project, I have other favorite framework. -james chris snow wrote: Hi James, I spent a lot of time looking at this and came to the conclusion that in 10.04 the dependencies between framework and applications became too intertwined to make a separate 10.04 framework. Here are some of the pages I put together documenting my steps: https://cwiki.apache.org/confluence/x/eIOJ https://cwiki.apache.org/confluence/x/nYTW I haven't used ofbiz for a while, however recently I started using ofbiz 9.04 and I may take another look at using 9.04 as the basis for some development effort to make ofbiz more modular (e.g. split the project up maven style and make the entity engine a separate project that can be used independently of ofbiz). There was also a interesting work by Raj to use OSGi to make the dependencies in ofbiz more explicit and controllable - https://sourceforge.net/projects/ofbiz-osgi/ David's new project is very interesting, because he will be 'vetting' all code that gets committed, which doesn't happen with the ofbiz svn repository. Cheers, Chris On Fri, Sep 17, 2010 at 3:24 AM, james_sgsnowme...@hotmail.com wrote: Does anyone know the status of this? --james BJ Freeman wrote: I am for standalone framework. David has been working on that project for a while, if I remember correctly. #2 bothers me though. The design of ofbiz was that the entity was the controlling factor for creating DB and UI. I was one of the major reasons I came to ofbiz. That said, any work that wants to be done on UI integration that makes ofbiz look classy, I think should be the focus. A lot of work has been done in that area. But integrating other UI interfaces that keep the design idea of the entity being to controlling focus is what I would like to see. I don't see ofbiz being object oriented in the normal sense. I see the effort for the help files and a easily understood UI from the user point of view being the main factors in promoting ofbiz. Chris Snow sent the following on 2/24/2010 10:47 PM: Here are some benefits of a 10.04 standalone framework release: 1) Standalone framework users would be a form of quality control helping to ensure more incorrect dependencies don't find there way into ofbiz. 2) we would be able to promote the framework in its own right thus competing with OpenERP's OpenObject platform 3) a much larger potential user base than ecommerce or erp users. Any more that I have missed? -- View this message in context: http://ofbiz.135035.n4.nabble.com/why-we-should-have-a-10-04-standalone-framework-release-tp1568563p2543258.html Sent from the OFBiz - User mailing list archive at Nabble.com. -- View this message in context: http://ofbiz.135035.n4.nabble.com/why-we-should-have-a-10-04-standalone-framework-release-tp1568563p2543697.html Sent from the OFBiz - User mailing list archive at Nabble.com.
Re: why we should have a 10.04 standalone framework release
I would see entity engine and service engine as separate modules. Each module should have clearly defined api defining how they interact with the outside world. A clearly defined api will facilitate swapping parts. For example, the entity engine could be replaced with a hibernate based engine as long as the api was implemented. (also there would be a module for Birt) On Fri, Sep 17, 2010 at 2:06 PM, BJ Freeman bjf...@free-man.net wrote: to me framework is what has not ability to interact with the real world, like party, but just the tools. so base layer is Entity and service engine. Next layer is Webapp and Widgets. next layer is Webtools next layer is security and common A person should be able to enable those things that they want for their application. chris snow sent the following on 9/17/2010 4:11 AM: If you follow my instructions for 9.04 that will to a large extent give you framework independence. I think 9.04 makes a good basis for looking at modularising parts of ofbiz. For example, I would like to see the entity engine live in its own project. The entity engine from what I remember is currently tightly tied in to performing duties such as reading configuration files. Based on this, I would next focus on giving the entity engine an api for loading it's global configuration and also component configurations. That way, the entity engine could be added to ofbiz as a pure jar file and be configured by some other module (e.g. a configuration service). Isolating parts of the system like the entity engine has a lot of benefits. For example, BJ Freeman has mentioned improvements to the entity engine such as on the fly entity changes. This would be made much easier if the entity engine was not so deeply intertwined with the rest of the ofbiz code. I think github would be the ideal place for hosting this kind of effort. That way non ofbiz commiters could more easily contribute. On Fri, Sep 17, 2010 at 11:49 AM, james_sgsnowme...@hotmail.com wrote: Hi Chris, I believe framework separation is a win-win situation and things will get sorted out when the common agreement is there. I am using 9.04. For non-erp project, I have other favorite framework. -james chris snow wrote: Hi James, I spent a lot of time looking at this and came to the conclusion that in 10.04 the dependencies between framework and applications became too intertwined to make a separate 10.04 framework. Here are some of the pages I put together documenting my steps: https://cwiki.apache.org/confluence/x/eIOJ https://cwiki.apache.org/confluence/x/nYTW I haven't used ofbiz for a while, however recently I started using ofbiz 9.04 and I may take another look at using 9.04 as the basis for some development effort to make ofbiz more modular (e.g. split the project up maven style and make the entity engine a separate project that can be used independently of ofbiz). There was also a interesting work by Raj to use OSGi to make the dependencies in ofbiz more explicit and controllable - https://sourceforge.net/projects/ofbiz-osgi/ David's new project is very interesting, because he will be 'vetting' all code that gets committed, which doesn't happen with the ofbiz svn repository. Cheers, Chris On Fri, Sep 17, 2010 at 3:24 AM, james_sgsnowme...@hotmail.com wrote: Does anyone know the status of this? --james BJ Freeman wrote: I am for standalone framework. David has been working on that project for a while, if I remember correctly. #2 bothers me though. The design of ofbiz was that the entity was the controlling factor for creating DB and UI. I was one of the major reasons I came to ofbiz. That said, any work that wants to be done on UI integration that makes ofbiz look classy, I think should be the focus. A lot of work has been done in that area. But integrating other UI interfaces that keep the design idea of the entity being to controlling focus is what I would like to see. I don't see ofbiz being object oriented in the normal sense. I see the effort for the help files and a easily understood UI from the user point of view being the main factors in promoting ofbiz. Chris Snow sent the following on 2/24/2010 10:47 PM: Here are some benefits of a 10.04 standalone framework release: 1) Standalone framework users would be a form of quality control helping to ensure more incorrect dependencies don't find there way into ofbiz. 2) we would be able to promote the framework in its own right thus competing with OpenERP's OpenObject platform 3) a much larger potential user base than ecommerce or erp users. Any more that I have missed? -- View this message in context: http://ofbiz.135035.n4.nabble.com/why-we-should-have-a-10-04-standalone-framework-release-tp1568563p2543258.html Sent from the OFBiz - User mailing list archive at Nabble.com. -- View this message in context:
Re: why we should have a 10.04 standalone framework release
Entity and service are seperate modules as they stand now. I would branch and leave ofbiz if the entity module was removed. it and how it relates to db and UI is why I came to ofbiz. I rejected hibernate and want nothing to do with them. = BJ Freeman http://bjfreeman.elance.com Strategic Power Office with Supplier Automation http://www.businessesnetwork.com/automation/viewforum.php?f=52 Specialtymarket.com http://www.specialtymarket.com/ Systems Integrator-- Glad to Assist Chat Y! messenger: bjfr33man chris snow sent the following on 9/17/2010 6:32 AM: I would see entity engine and service engine as separate modules. Each module should have clearly defined api defining how they interact with the outside world. A clearly defined api will facilitate swapping parts. For example, the entity engine could be replaced with a hibernate based engine as long as the api was implemented. (also there would be a module for Birt) On Fri, Sep 17, 2010 at 2:06 PM, BJ Freemanbjf...@free-man.net wrote: to me framework is what has not ability to interact with the real world, like party, but just the tools. so base layer is Entity and service engine. Next layer is Webapp and Widgets. next layer is Webtools next layer is security and common A person should be able to enable those things that they want for their application. chris snow sent the following on 9/17/2010 4:11 AM: If you follow my instructions for 9.04 that will to a large extent give you framework independence. I think 9.04 makes a good basis for looking at modularising parts of ofbiz. For example, I would like to see the entity engine live in its own project. The entity engine from what I remember is currently tightly tied in to performing duties such as reading configuration files. Based on this, I would next focus on giving the entity engine an api for loading it's global configuration and also component configurations. That way, the entity engine could be added to ofbiz as a pure jar file and be configured by some other module (e.g. a configuration service). Isolating parts of the system like the entity engine has a lot of benefits. For example, BJ Freeman has mentioned improvements to the entity engine such as on the fly entity changes. This would be made much easier if the entity engine was not so deeply intertwined with the rest of the ofbiz code. I think github would be the ideal place for hosting this kind of effort. That way non ofbiz commiters could more easily contribute. On Fri, Sep 17, 2010 at 11:49 AM, james_sgsnowme...@hotmail.comwrote: Hi Chris, I believe framework separation is a win-win situation and things will get sorted out when the common agreement is there. I am using 9.04. For non-erp project, I have other favorite framework. -james chris snow wrote: Hi James, I spent a lot of time looking at this and came to the conclusion that in 10.04 the dependencies between framework and applications became too intertwined to make a separate 10.04 framework. Here are some of the pages I put together documenting my steps: https://cwiki.apache.org/confluence/x/eIOJ https://cwiki.apache.org/confluence/x/nYTW I haven't used ofbiz for a while, however recently I started using ofbiz 9.04 and I may take another look at using 9.04 as the basis for some development effort to make ofbiz more modular (e.g. split the project up maven style and make the entity engine a separate project that can be used independently of ofbiz). There was also a interesting work by Raj to use OSGi to make the dependencies in ofbiz more explicit and controllable - https://sourceforge.net/projects/ofbiz-osgi/ David's new project is very interesting, because he will be 'vetting' all code that gets committed, which doesn't happen with the ofbiz svn repository. Cheers, Chris On Fri, Sep 17, 2010 at 3:24 AM, james_sgsnowme...@hotmail.comwrote: Does anyone know the status of this? --james BJ Freeman wrote: I am for standalone framework. David has been working on that project for a while, if I remember correctly. #2 bothers me though. The design of ofbiz was that the entity was the controlling factor for creating DB and UI. I was one of the major reasons I came to ofbiz. That said, any work that wants to be done on UI integration that makes ofbiz look classy, I think should be the focus. A lot of work has been done in that area. But integrating other UI interfaces that keep the design idea of the entity being to controlling focus is what I would like to see. I don't see ofbiz being object oriented in the normal sense. I see the effort for the help files and a easily understood UI from the user point of view being the main factors in promoting ofbiz. Chris Snow sent the following on 2/24/2010 10:47 PM: Here are some benefits of a 10.04 standalone framework release: 1) Standalone framework users would be a form of quality control helping to ensure more incorrect dependencies don't find there
Re: why we should have a 10.04 standalone framework release
Hi Chris, Could you explain how you envisage swapping the entity engine with hibernate considering one uses Maps (GenericValue) and the other uses POJOs to represent data? Thanks Scott HotWax Media http://www.hotwaxmedia.com On 18/09/2010, at 1:32 AM, chris snow wrote: I would see entity engine and service engine as separate modules. Each module should have clearly defined api defining how they interact with the outside world. A clearly defined api will facilitate swapping parts. For example, the entity engine could be replaced with a hibernate based engine as long as the api was implemented. (also there would be a module for Birt) On Fri, Sep 17, 2010 at 2:06 PM, BJ Freeman bjf...@free-man.net wrote: to me framework is what has not ability to interact with the real world, like party, but just the tools. so base layer is Entity and service engine. Next layer is Webapp and Widgets. next layer is Webtools next layer is security and common A person should be able to enable those things that they want for their application. chris snow sent the following on 9/17/2010 4:11 AM: If you follow my instructions for 9.04 that will to a large extent give you framework independence. I think 9.04 makes a good basis for looking at modularising parts of ofbiz. For example, I would like to see the entity engine live in its own project. The entity engine from what I remember is currently tightly tied in to performing duties such as reading configuration files. Based on this, I would next focus on giving the entity engine an api for loading it's global configuration and also component configurations. That way, the entity engine could be added to ofbiz as a pure jar file and be configured by some other module (e.g. a configuration service). Isolating parts of the system like the entity engine has a lot of benefits. For example, BJ Freeman has mentioned improvements to the entity engine such as on the fly entity changes. This would be made much easier if the entity engine was not so deeply intertwined with the rest of the ofbiz code. I think github would be the ideal place for hosting this kind of effort. That way non ofbiz commiters could more easily contribute. On Fri, Sep 17, 2010 at 11:49 AM, james_sgsnowme...@hotmail.com wrote: Hi Chris, I believe framework separation is a win-win situation and things will get sorted out when the common agreement is there. I am using 9.04. For non-erp project, I have other favorite framework. -james chris snow wrote: Hi James, I spent a lot of time looking at this and came to the conclusion that in 10.04 the dependencies between framework and applications became too intertwined to make a separate 10.04 framework. Here are some of the pages I put together documenting my steps: https://cwiki.apache.org/confluence/x/eIOJ https://cwiki.apache.org/confluence/x/nYTW I haven't used ofbiz for a while, however recently I started using ofbiz 9.04 and I may take another look at using 9.04 as the basis for some development effort to make ofbiz more modular (e.g. split the project up maven style and make the entity engine a separate project that can be used independently of ofbiz). There was also a interesting work by Raj to use OSGi to make the dependencies in ofbiz more explicit and controllable - https://sourceforge.net/projects/ofbiz-osgi/ David's new project is very interesting, because he will be 'vetting' all code that gets committed, which doesn't happen with the ofbiz svn repository. Cheers, Chris On Fri, Sep 17, 2010 at 3:24 AM, james_sgsnowme...@hotmail.com wrote: Does anyone know the status of this? --james BJ Freeman wrote: I am for standalone framework. David has been working on that project for a while, if I remember correctly. #2 bothers me though. The design of ofbiz was that the entity was the controlling factor for creating DB and UI. I was one of the major reasons I came to ofbiz. That said, any work that wants to be done on UI integration that makes ofbiz look classy, I think should be the focus. A lot of work has been done in that area. But integrating other UI interfaces that keep the design idea of the entity being to controlling focus is what I would like to see. I don't see ofbiz being object oriented in the normal sense. I see the effort for the help files and a easily understood UI from the user point of view being the main factors in promoting ofbiz. Chris Snow sent the following on 2/24/2010 10:47 PM: Here are some benefits of a 10.04 standalone framework release: 1) Standalone framework users would be a form of quality control helping to ensure more incorrect dependencies don't find there way into ofbiz. 2) we would be able to promote the framework in its own right thus competing with OpenERP's OpenObject platform 3) a much larger potential user base than ecommerce or erp users. Any
Re: why we should have a 10.04 standalone framework release
Does anyone know the status of this? --james BJ Freeman wrote: I am for standalone framework. David has been working on that project for a while, if I remember correctly. #2 bothers me though. The design of ofbiz was that the entity was the controlling factor for creating DB and UI. I was one of the major reasons I came to ofbiz. That said, any work that wants to be done on UI integration that makes ofbiz look classy, I think should be the focus. A lot of work has been done in that area. But integrating other UI interfaces that keep the design idea of the entity being to controlling focus is what I would like to see. I don't see ofbiz being object oriented in the normal sense. I see the effort for the help files and a easily understood UI from the user point of view being the main factors in promoting ofbiz. Chris Snow sent the following on 2/24/2010 10:47 PM: Here are some benefits of a 10.04 standalone framework release: 1) Standalone framework users would be a form of quality control helping to ensure more incorrect dependencies don't find there way into ofbiz. 2) we would be able to promote the framework in its own right thus competing with OpenERP's OpenObject platform 3) a much larger potential user base than ecommerce or erp users. Any more that I have missed? -- View this message in context: http://ofbiz.135035.n4.nabble.com/why-we-should-have-a-10-04-standalone-framework-release-tp1568563p2543258.html Sent from the OFBiz - User mailing list archive at Nabble.com.
Re: why we should have a 10.04 standalone framework release
A long time ago I did work on this, but I haven't for years. The topic has come up a few times, and I like the idea, which is why in my more recent effort I'm starting with an independent framework (Moqui) that will never have applications in the same project that it might depend on. There have been a few reviews and efforts here and there to make the framework independent again, ie to be fully functional without the applications components in place. I'm not aware of anyone working on that now. Right now it seems like the goal that is presenting a challenge is to avoid new dependencies from the framework components to the applications components. Perhaps someday this will become a priority again in the community, but the fact of the matter is that people work on and contribute things that are of interest or use to them, and this state of things means simply that not enough people who are willing to contribute find a use or interest in this... :) -David On Sep 16, 2010, at 8:24 PM, james_sg wrote: Does anyone know the status of this? --james BJ Freeman wrote: I am for standalone framework. David has been working on that project for a while, if I remember correctly. #2 bothers me though. The design of ofbiz was that the entity was the controlling factor for creating DB and UI. I was one of the major reasons I came to ofbiz. That said, any work that wants to be done on UI integration that makes ofbiz look classy, I think should be the focus. A lot of work has been done in that area. But integrating other UI interfaces that keep the design idea of the entity being to controlling focus is what I would like to see. I don't see ofbiz being object oriented in the normal sense. I see the effort for the help files and a easily understood UI from the user point of view being the main factors in promoting ofbiz. Chris Snow sent the following on 2/24/2010 10:47 PM: Here are some benefits of a 10.04 standalone framework release: 1) Standalone framework users would be a form of quality control helping to ensure more incorrect dependencies don't find there way into ofbiz. 2) we would be able to promote the framework in its own right thus competing with OpenERP's OpenObject platform 3) a much larger potential user base than ecommerce or erp users. Any more that I have missed? -- View this message in context: http://ofbiz.135035.n4.nabble.com/why-we-should-have-a-10-04-standalone-framework-release-tp1568563p2543258.html Sent from the OFBiz - User mailing list archive at Nabble.com.
Re: why we should have a 10.04 standalone framework release
the only one that seems active in this is Bruno one such effort. https://issues.apache.org/jira/browse/OFBIZ-3894 james_sg sent the following on 9/16/2010 7:24 PM: Does anyone know the status of this? --james BJ Freeman wrote: I am for standalone framework. David has been working on that project for a while, if I remember correctly. #2 bothers me though. The design of ofbiz was that the entity was the controlling factor for creating DB and UI. I was one of the major reasons I came to ofbiz. That said, any work that wants to be done on UI integration that makes ofbiz look classy, I think should be the focus. A lot of work has been done in that area. But integrating other UI interfaces that keep the design idea of the entity being to controlling focus is what I would like to see. I don't see ofbiz being object oriented in the normal sense. I see the effort for the help files and a easily understood UI from the user point of view being the main factors in promoting ofbiz. Chris Snow sent the following on 2/24/2010 10:47 PM: Here are some benefits of a 10.04 standalone framework release: 1) Standalone framework users would be a form of quality control helping to ensure more incorrect dependencies don't find there way into ofbiz. 2) we would be able to promote the framework in its own right thus competing with OpenERP's OpenObject platform 3) a much larger potential user base than ecommerce or erp users. Any more that I have missed?
Re: why we should have a 10.04 standalone framework release
I think a common agreement is needed among developers on whether OFBiz should have a standalone framework. If a common agreement is reached, then we need to have a common understanding on how things should be done, so that people plays by the rule. Which function to move into the standalone framework can be discussed later. The one with the least dependence can go in first. At least, things are moving... My 2 cents. --james BJ Freeman wrote: the only one that seems active in this is Bruno one such effort. https://issues.apache.org/jira/browse/OFBIZ-3894 james_sg sent the following on 9/16/2010 7:24 PM: Does anyone know the status of this? --james BJ Freeman wrote: I am for standalone framework. David has been working on that project for a while, if I remember correctly. #2 bothers me though. The design of ofbiz was that the entity was the controlling factor for creating DB and UI. I was one of the major reasons I came to ofbiz. That said, any work that wants to be done on UI integration that makes ofbiz look classy, I think should be the focus. A lot of work has been done in that area. But integrating other UI interfaces that keep the design idea of the entity being to controlling focus is what I would like to see. I don't see ofbiz being object oriented in the normal sense. I see the effort for the help files and a easily understood UI from the user point of view being the main factors in promoting ofbiz. Chris Snow sent the following on 2/24/2010 10:47 PM: Here are some benefits of a 10.04 standalone framework release: 1) Standalone framework users would be a form of quality control helping to ensure more incorrect dependencies don't find there way into ofbiz. 2) we would be able to promote the framework in its own right thus competing with OpenERP's OpenObject platform 3) a much larger potential user base than ecommerce or erp users. Any more that I have missed? -- View this message in context: http://ofbiz.135035.n4.nabble.com/why-we-should-have-a-10-04-standalone-framework-release-tp1568563p2543310.html Sent from the OFBiz - User mailing list archive at Nabble.com.
Re: why we should have a 10.04 standalone framework release
Hi James, I did write a wiki page to define how the framework only distribution should be shaped. Following that there was some mail thread in which we discussed about. Some of us was not on the same page but we did not agree on something different that could be written updating the wiki page. You can find the wiki page here: https://cwiki.apache.org/confluence/display/OFBIZ/Framework-only+distribution Fill free to express your opinion and help on that. A contribute that will gine IMO a great help on framework independence is also: https://issues.apache.org/jira/browse/OFBIZ-3373 Scott is working on that and I am looking forward to it. -Bruno 2010/9/17 james_sg snowme...@hotmail.com I think a common agreement is needed among developers on whether OFBiz should have a standalone framework. If a common agreement is reached, then we need to have a common understanding on how things should be done, so that people plays by the rule. Which function to move into the standalone framework can be discussed later. The one with the least dependence can go in first. At least, things are moving... My 2 cents. --james BJ Freeman wrote: the only one that seems active in this is Bruno one such effort. https://issues.apache.org/jira/browse/OFBIZ-3894 james_sg sent the following on 9/16/2010 7:24 PM: Does anyone know the status of this? --james BJ Freeman wrote: I am for standalone framework. David has been working on that project for a while, if I remember correctly. #2 bothers me though. The design of ofbiz was that the entity was the controlling factor for creating DB and UI. I was one of the major reasons I came to ofbiz. That said, any work that wants to be done on UI integration that makes ofbiz look classy, I think should be the focus. A lot of work has been done in that area. But integrating other UI interfaces that keep the design idea of the entity being to controlling focus is what I would like to see. I don't see ofbiz being object oriented in the normal sense. I see the effort for the help files and a easily understood UI from the user point of view being the main factors in promoting ofbiz. Chris Snow sent the following on 2/24/2010 10:47 PM: Here are some benefits of a 10.04 standalone framework release: 1) Standalone framework users would be a form of quality control helping to ensure more incorrect dependencies don't find there way into ofbiz. 2) we would be able to promote the framework in its own right thus competing with OpenERP's OpenObject platform 3) a much larger potential user base than ecommerce or erp users. Any more that I have missed? -- View this message in context: http://ofbiz.135035.n4.nabble.com/why-we-should-have-a-10-04-standalone-framework-release-tp1568563p2543310.html Sent from the OFBiz - User mailing list archive at Nabble.com.
Re: why we should have a 10.04 standalone framework release
I am for standalone framework. David has been working on that project for a while, if I remember correctly. #2 bothers me though. The design of ofbiz was that the entity was the controlling factor for creating DB and UI. I was one of the major reasons I came to ofbiz. That said, any work that wants to be done on UI integration that makes ofbiz look classy, I think should be the focus. A lot of work has been done in that area. But integrating other UI interfaces that keep the design idea of the entity being to controlling focus is what I would like to see. I don't see ofbiz being object oriented in the normal sense. I see the effort for the help files and a easily understood UI from the user point of view being the main factors in promoting ofbiz. Chris Snow sent the following on 2/24/2010 10:47 PM: Here are some benefits of a 10.04 standalone framework release: 1) Standalone framework users would be a form of quality control helping to ensure more incorrect dependencies don't find there way into ofbiz. 2) we would be able to promote the framework in its own right thus competing with OpenERP's OpenObject platform 3) a much larger potential user base than ecommerce or erp users. Any more that I have missed?
why we should have a 10.04 standalone framework release
Here are some benefits of a 10.04 standalone framework release: 1) Standalone framework users would be a form of quality control helping to ensure more incorrect dependencies don't find there way into ofbiz. 2) we would be able to promote the framework in its own right thus competing with OpenERP's OpenObject platform 3) a much larger potential user base than ecommerce or erp users. Any more that I have missed? -- Chris Snow - CEng MBCS CITP MBA (Tech Mgmt) (Open) CISSP Tel: 01453 890660 Mob: 07944 880950 Www: www.snowconsulting.co.uk
why we should have a 10.04 standalone framework release
Here are some benefits of a 10.04 standalone framework release: 1) Standalone framework users would be a form of quality control helping to ensure more incorrect dependencies don't find there way into ofbiz. 2) we would be able to promote the framework in its own right thus competing with OpenERP's OpenObject platform 3) a much larger potential user base than ecommerce or erp users. Any more that I have missed? -- Chris Snow - CEng MBCS CITP MBA (Tech Mgmt) (Open) CISSP Tel: 01453 890660 Mob: 07944 880950 Www: www.snowconsulting.co.uk
