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/
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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:
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
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
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
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
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
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
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
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
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
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
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
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
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.
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
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
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
36 matches
Mail list logo
