Brain-storm: OFBIZ on Grails, is this a right way for the future?

[Ruth Hoffman-2]

Hi Jacopo:

IMO, one should always give positive affirmations when responding to
posts like these. OFBiz has plenty of great things we can say that
shouldn't require much effort on your part to comment on:

How about the seamless and transparent database support by way of the
Entity Engine?  If you want to develop an application or implement ERP,
then you don't need to worry about the database. You don't need to
stress over whether to use Hiberanate or JDO or native SQL or whatever
the latest database technology fad happens to be. The EE is here, its
proven and best of all I don't have to deal with it! I can get on to
developing my applications.

Or the really cool Service Engine that lets me write reusable code. Java
or otherwise!

Or all the framework tools that have been integrated and proven.
Everything from Internationalization and localization support to XML
document handling. (Personally, I'm tired of having to integrate XML
parsers every time I need that functionality in an application.)

How hard is it to list some of these features? Take the "high road".

Ruth



Jacopo Cappellato wrote:

> On Feb 26, 2010, at 2:27 PM, Christopher Snow wrote:
>
>  
>> Hey come on Jacopo - overall I'm actually trying to promote the use of ofbiz.  I've invested a considerable amount of time in it.
>>
>> I was hoping that my question would get ofbiz supporters to list some of the benefits of ofbiz over grails.
>>
>>    
>
> Eh eh... this time your attempt will not help you to get easy information (at least from me): you will have to do your own research :-)
>
> Jacopo
>
>
>  
>> Jacopo Cappellato wrote:
>>    
>>> On Feb 26, 2010, at 1:20 PM, Christopher Snow wrote:
>>>
>>>  
>>>      
>>>>> I can't think of anything other than this that the ofbiz framework provides that grails doesn't.
>>>>>      
>>>>>          
>>> If you are blind, all you can see is darkness.
>>>
>>> Jacopo
>>>
>>>  
>>>      
>
>
>  

[Jacques Le Roux]

And one of the most important thing but not obvious in OFBiz,  extension and reutilisation of artifacts.
From hot-deploy, you can build your own applicaiton based on the trunk (or release but I'd recommend trunk for easier update later)
without touching much of OFBiz itself. If you handle it right you may end with a couple of small patches. There are even small tools
around, see ant - p, to deal with hat. This is where is the real OFBiz expertise, it takes some time to understand and use...
Also OFBiz is *great* when it comes to *not* compile, reboot, compile, reboot, compile, reboot, compile, reboot, compile, reboot,
compile, reboot, OK you see...

Jacques

From: "Ruth Hoffman" <[hidden email]>

> Hi Jacopo:
>
> IMO, one should always give positive affirmations when responding to posts like these. OFBiz has plenty of great things we can say
> that shouldn't require much effort on your part to comment on:
>
> How about the seamless and transparent database support by way of the Entity Engine?  If you want to develop an application or
> implement ERP, then you don't need to worry about the database. You don't need to stress over whether to use Hiberanate or JDO or
> native SQL or whatever the latest database technology fad happens to be. The EE is here, its proven and best of all I don't have
> to deal with it! I can get on to developing my applications.
>
> Or the really cool Service Engine that lets me write reusable code. Java or otherwise!
>
> Or all the framework tools that have been integrated and proven. Everything from Internationalization and localization support to
> XML document handling. (Personally, I'm tired of having to integrate XML parsers every time I need that functionality in an
> application.)
>
> How hard is it to list some of these features? Take the "high road".
>
> Ruth
>
>
>
> Jacopo Cappellato wrote:
>> On Feb 26, 2010, at 2:27 PM, Christopher Snow wrote:
>>
>>
>>> Hey come on Jacopo - overall I'm actually trying to promote the use of ofbiz.  I've invested a considerable amount of time in
>>> it.
>>>
>>> I was hoping that my question would get ofbiz supporters to list some of the benefits of ofbiz over grails.
>>>
>>>
>>
>> Eh eh... this time your attempt will not help you to get easy information (at least from me): you will have to do your own
>> research :-)
>>
>> Jacopo
>>
>>
>>
>>> Jacopo Cappellato wrote:
>>>
>>>> On Feb 26, 2010, at 1:20 PM, Christopher Snow wrote:
>>>>
>>>>
>>>>>> I can't think of anything other than this that the ofbiz framework provides that grails doesn't.
>>>>>>
>>>> If you are blind, all you can see is darkness.
>>>>
>>>> Jacopo
>>>>
>>>>
>>
>>
>>
>

[Ruth Hoffman-2]

Please, keep these coming! I certainly could use a refresher.
Ruth

Jacques Le Roux wrote:

> And one of the most important thing but not obvious in OFBiz,  
> extension and reutilisation of artifacts.
>> From hot-deploy, you can build your own applicaiton based on the
>> trunk (or release but I'd recommend trunk for easier update later)
> without touching much of OFBiz itself. If you handle it right you may
> end with a couple of small patches. There are even small tools around,
> see ant - p, to deal with hat. This is where is the real OFBiz
> expertise, it takes some time to understand and use...
> Also OFBiz is *great* when it comes to *not* compile, reboot, compile,
> reboot, compile, reboot, compile, reboot, compile, reboot, compile,
> reboot, OK you see...
>
> Jacques
>
> From: "Ruth Hoffman" <[hidden email]>
>
>
>> Hi Jacopo:
>>
>> IMO, one should always give positive affirmations when responding to
>> posts like these. OFBiz has plenty of great things we can say that
>> shouldn't require much effort on your part to comment on:
>>
>> How about the seamless and transparent database support by way of the
>> Entity Engine?  If you want to develop an application or implement
>> ERP, then you don't need to worry about the database. You don't need
>> to stress over whether to use Hiberanate or JDO or native SQL or
>> whatever the latest database technology fad happens to be. The EE is
>> here, its proven and best of all I don't have to deal with it! I can
>> get on to developing my applications.
>>
>> Or the really cool Service Engine that lets me write reusable code.
>> Java or otherwise!
>>
>> Or all the framework tools that have been integrated and proven.
>> Everything from Internationalization and localization support to XML
>> document handling. (Personally, I'm tired of having to integrate XML
>> parsers every time I need that functionality in an application.)
>>
>> How hard is it to list some of these features? Take the "high road".
>>
>> Ruth
>>
>>
>>
>> Jacopo Cappellato wrote:
>>> On Feb 26, 2010, at 2:27 PM, Christopher Snow wrote:
>>>
>>>
>>>> Hey come on Jacopo - overall I'm actually trying to promote the use
>>>> of ofbiz.  I've invested a considerable amount of time in it.
>>>>
>>>> I was hoping that my question would get ofbiz supporters to list
>>>> some of the benefits of ofbiz over grails.
>>>>
>>>>
>>>
>>> Eh eh... this time your attempt will not help you to get easy
>>> information (at least from me): you will have to do your own
>>> research :-)
>>>
>>> Jacopo
>>>
>>>
>>>
>>>> Jacopo Cappellato wrote:
>>>>
>>>>> On Feb 26, 2010, at 1:20 PM, Christopher Snow wrote:
>>>>>
>>>>>
>>>>>>> I can't think of anything other than this that the ofbiz
>>>>>>> framework provides that grails doesn't.
>>>>>>>
>>>>> If you are blind, all you can see is darkness.
>>>>>
>>>>> Jacopo
>>>>>
>>>>>
>>>
>>>
>>>
>>
>
>
>

[Chris Snow-3]

Hi Jacques,

Thanks for the comments.

Not sure how grails handles extension of artifacts (except that
Controllers and Services are classes so theoretically could be extended).

Grails only needs to be restarted when the hibernate definitions have
changed (I think). Controller and Service changes are dynamically
reloaded in development mode without a restart.

Grails has:  |"grails create-app helloworld" which is the equivalent of
creating an ofbiz component.

In ofbiz, I always have to jump into the ofbiz code, even if its just to
configure it (e.g. data sources).  In grails, the component
configuration is done in the component itself.  I would never expect you
to modify the core grails code and create patches to ship with your
application - this is a big disadvantage with ofbiz.

Please don't think I'm giving ofbiz a hard time.  Don't forget, I'm
interested in creating a standalone ofbiz framework (which would be
especially useful for my current government client), but I'm not sure
that the framework on it's own carrys any benefits compared to grails.  
It's the business applications that give ofbiz the most advantage.

Cheers,

Chris
|

Jacques Le Roux wrote:

> And one of the most important thing but not obvious in OFBiz,  
> extension and reutilisation of artifacts.
> From hot-deploy, you can build your own applicaiton based on the trunk
> (or release but I'd recommend trunk for easier update later) without
> touching much of OFBiz itself. If you handle it right you may end with
> a couple of small patches. There are even small tools around, see ant
> - p, to deal with hat. This is where is the real OFBiz expertise, it
> takes some time to understand and use...
> Also OFBiz is *great* when it comes to *not* compile, reboot, compile,
> reboot, compile, reboot, compile, reboot, compile, reboot, compile,
> reboot, OK you see...
>
> Jacques
>
> From: "Ruth Hoffman" <[hidden email]>
>
>
>> Hi Jacopo:
>>
>> IMO, one should always give positive affirmations when responding to
>> posts like these. OFBiz has plenty of great things we can say that
>> shouldn't require much effort on your part to comment on:
>>
>> How about the seamless and transparent database support by way of the
>> Entity Engine?  If you want to develop an application or implement
>> ERP, then you don't need to worry about the database. You don't need
>> to stress over whether to use Hiberanate or JDO or native SQL or
>> whatever the latest database technology fad happens to be. The EE is
>> here, its proven and best of all I don't have to deal with it! I can
>> get on to developing my applications.
>>
>> Or the really cool Service Engine that lets me write reusable code.
>> Java or otherwise!
>>
>> Or all the framework tools that have been integrated and proven.
>> Everything from Internationalization and localization support to XML
>> document handling. (Personally, I'm tired of having to integrate XML
>> parsers every time I need that functionality in an application.)
>>
>> How hard is it to list some of these features? Take the "high road".
>>
>> Ruth
>>
>>
>>
>> Jacopo Cappellato wrote:
>>> On Feb 26, 2010, at 2:27 PM, Christopher Snow wrote:
>>>
>>>
>>>> Hey come on Jacopo - overall I'm actually trying to promote the use
>>>> of ofbiz.  I've invested a considerable amount of time in it.
>>>>
>>>> I was hoping that my question would get ofbiz supporters to list
>>>> some of the benefits of ofbiz over grails.
>>>>
>>>>
>>>
>>> Eh eh... this time your attempt will not help you to get easy
>>> information (at least from me): you will have to do your own
>>> research :-)
>>>
>>> Jacopo
>>>
>>>
>>>
>>>> Jacopo Cappellato wrote:
>>>>
>>>>> On Feb 26, 2010, at 1:20 PM, Christopher Snow wrote:
>>>>>
>>>>>
>>>>>>> I can't think of anything other than this that the ofbiz
>>>>>>> framework provides that grails doesn't.
>>>>>>>
>>>>> If you are blind, all you can see is darkness.
>>>>>
>>>>> Jacopo
>>>>>
>>>>>
>>>
>>>
>>>
>>
>
>

[Jacques Le Roux]

I hope to get some time to get this more clear one day...

Jacques

From: "Ruth Hoffman" <[hidden email]>

> Please, keep these coming! I certainly could use a refresher.
> Ruth
>
> Jacques Le Roux wrote:
>> And one of the most important thing but not obvious in OFBiz,  
>> extension and reutilisation of artifacts.
>>> From hot-deploy, you can build your own applicaiton based on the
>>> trunk (or release but I'd recommend trunk for easier update later)
>> without touching much of OFBiz itself. If you handle it right you may
>> end with a couple of small patches. There are even small tools around,
>> see ant - p, to deal with hat. This is where is the real OFBiz
>> expertise, it takes some time to understand and use...
>> Also OFBiz is *great* when it comes to *not* compile, reboot, compile,
>> reboot, compile, reboot, compile, reboot, compile, reboot, compile,
>> reboot, OK you see...
>>
>> Jacques
>>
>> From: "Ruth Hoffman" <[hidden email]>
>>
>>
>>> Hi Jacopo:
>>>
>>> IMO, one should always give positive affirmations when responding to
>>> posts like these. OFBiz has plenty of great things we can say that
>>> shouldn't require much effort on your part to comment on:
>>>
>>> How about the seamless and transparent database support by way of the
>>> Entity Engine?  If you want to develop an application or implement
>>> ERP, then you don't need to worry about the database. You don't need
>>> to stress over whether to use Hiberanate or JDO or native SQL or
>>> whatever the latest database technology fad happens to be. The EE is
>>> here, its proven and best of all I don't have to deal with it! I can
>>> get on to developing my applications.
>>>
>>> Or the really cool Service Engine that lets me write reusable code.
>>> Java or otherwise!
>>>
>>> Or all the framework tools that have been integrated and proven.
>>> Everything from Internationalization and localization support to XML
>>> document handling. (Personally, I'm tired of having to integrate XML
>>> parsers every time I need that functionality in an application.)
>>>
>>> How hard is it to list some of these features? Take the "high road".
>>>
>>> Ruth
>>>
>>>
>>>
>>> Jacopo Cappellato wrote:
>>>> On Feb 26, 2010, at 2:27 PM, Christopher Snow wrote:
>>>>
>>>>
>>>>> Hey come on Jacopo - overall I'm actually trying to promote the use
>>>>> of ofbiz.  I've invested a considerable amount of time in it.
>>>>>
>>>>> I was hoping that my question would get ofbiz supporters to list
>>>>> some of the benefits of ofbiz over grails.
>>>>>
>>>>>
>>>>
>>>> Eh eh... this time your attempt will not help you to get easy
>>>> information (at least from me): you will have to do your own
>>>> research :-)
>>>>
>>>> Jacopo
>>>>
>>>>
>>>>
>>>>> Jacopo Cappellato wrote:
>>>>>
>>>>>> On Feb 26, 2010, at 1:20 PM, Christopher Snow wrote:
>>>>>>
>>>>>>
>>>>>>>> I can't think of anything other than this that the ofbiz
>>>>>>>> framework provides that grails doesn't.
>>>>>>>>
>>>>>> If you are blind, all you can see is darkness.
>>>>>>
>>>>>> Jacopo
>>>>>>
>>>>>>
>>>>
>>>>
>>>>
>>>
>>
>>
>>
>

[Jacques Le Roux]

I'm more speaking at the business level . You may reuse artifacts there...

Jacques

From: "Christopher Snow" <[hidden email]>

> Hi Jacques,
>
> Thanks for the comments.
>
> Not sure how grails handles extension of artifacts (except that
> Controllers and Services are classes so theoretically could be extended).
>
> Grails only needs to be restarted when the hibernate definitions have
> changed (I think). Controller and Service changes are dynamically
> reloaded in development mode without a restart.
>
> Grails has:  |"grails create-app helloworld" which is the equivalent of
> creating an ofbiz component.
>
> In ofbiz, I always have to jump into the ofbiz code, even if its just to
> configure it (e.g. data sources).  In grails, the component
> configuration is done in the component itself.  I would never expect you
> to modify the core grails code and create patches to ship with your
> application - this is a big disadvantage with ofbiz.
>
> Please don't think I'm giving ofbiz a hard time.  Don't forget, I'm
> interested in creating a standalone ofbiz framework (which would be
> especially useful for my current government client), but I'm not sure
> that the framework on it's own carrys any benefits compared to grails.  
> It's the business applications that give ofbiz the most advantage.
>
> Cheers,
>
> Chris
> |
>
> Jacques Le Roux wrote:
>> And one of the most important thing but not obvious in OFBiz,  
>> extension and reutilisation of artifacts.
>> From hot-deploy, you can build your own applicaiton based on the trunk
>> (or release but I'd recommend trunk for easier update later) without
>> touching much of OFBiz itself. If you handle it right you may end with
>> a couple of small patches. There are even small tools around, see ant
>> - p, to deal with hat. This is where is the real OFBiz expertise, it
>> takes some time to understand and use...
>> Also OFBiz is *great* when it comes to *not* compile, reboot, compile,
>> reboot, compile, reboot, compile, reboot, compile, reboot, compile,
>> reboot, OK you see...
>>
>> Jacques
>>
>> From: "Ruth Hoffman" <[hidden email]>
>>
>>
>>> Hi Jacopo:
>>>
>>> IMO, one should always give positive affirmations when responding to
>>> posts like these. OFBiz has plenty of great things we can say that
>>> shouldn't require much effort on your part to comment on:
>>>
>>> How about the seamless and transparent database support by way of the
>>> Entity Engine?  If you want to develop an application or implement
>>> ERP, then you don't need to worry about the database. You don't need
>>> to stress over whether to use Hiberanate or JDO or native SQL or
>>> whatever the latest database technology fad happens to be. The EE is
>>> here, its proven and best of all I don't have to deal with it! I can
>>> get on to developing my applications.
>>>
>>> Or the really cool Service Engine that lets me write reusable code.
>>> Java or otherwise!
>>>
>>> Or all the framework tools that have been integrated and proven.
>>> Everything from Internationalization and localization support to XML
>>> document handling. (Personally, I'm tired of having to integrate XML
>>> parsers every time I need that functionality in an application.)
>>>
>>> How hard is it to list some of these features? Take the "high road".
>>>
>>> Ruth
>>>
>>>
>>>
>>> Jacopo Cappellato wrote:
>>>> On Feb 26, 2010, at 2:27 PM, Christopher Snow wrote:
>>>>
>>>>
>>>>> Hey come on Jacopo - overall I'm actually trying to promote the use
>>>>> of ofbiz.  I've invested a considerable amount of time in it.
>>>>>
>>>>> I was hoping that my question would get ofbiz supporters to list
>>>>> some of the benefits of ofbiz over grails.
>>>>>
>>>>>
>>>>
>>>> Eh eh... this time your attempt will not help you to get easy
>>>> information (at least from me): you will have to do your own
>>>> research :-)
>>>>
>>>> Jacopo
>>>>
>>>>
>>>>
>>>>> Jacopo Cappellato wrote:
>>>>>
>>>>>> On Feb 26, 2010, at 1:20 PM, Christopher Snow wrote:
>>>>>>
>>>>>>
>>>>>>>> I can't think of anything other than this that the ofbiz
>>>>>>>> framework provides that grails doesn't.
>>>>>>>>
>>>>>> If you are blind, all you can see is darkness.
>>>>>>
>>>>>> Jacopo
>>>>>>
>>>>>>
>>>>
>>>>
>>>>
>>>
>>
>>
>

[Miles Huang]

Please see inline...

On Fri, 2010-02-26 at 12:20 +0000, Christopher Snow wrote:
> One more - inline...
>
> Christopher Snow wrote:
> > Hi Miles,
> >
> > I'm currently doing some work on making a standalone ofbiz development
> > framework (i.e. no business functionality).  Your questions have got
> > me thinking:
> >
Interesting work. Will future OFBIZ official release based on this
framework? Is there any preview working code in repository now?

> >   "what does the ofbiz framework give you that the grails framework
> > doesn't?"

Yes. That's why I've started this topic. Since someone is dedicated in
inventing wheel and do well, why OFBIZ keep home-made one?
Consider the maintenance effort you are currently spending. And consider
if OFBIZ will last another decade (I really hope so), how many effort
will spend in keeping OFBIZ catch on the new technology evolve, like
recently mentioned OSGi, etc...

> >
> > A possible answer:
> >
> >   "Ofbiz gives you a ready made layout for backend management UI (i.e.
> > screens, menus, forms)"

Beg me to argue that This is a higher UI level functionality. Grails has
also its way to do UI-level component composition, based on decoration
pattern. For the real problem, see next section.

> the ofbiz framework will give you an easy upgrade path to the full ofbiz
> and all its business functionality.
Yes, this is the first class factor. Although to write a new component
in Grails is trival, to provide the new Grails code all/most ability to
access the current OFBIZ business functionality and integrated it into
the current OFBIZ framework is really a big challenge. The problem
exists on every tier: persistence entity, service/event, widget. In
every tier OFBIZ has its unique implementation technology and OFBIZ
components seems to coupling on every tier, a little tight coupling, I
think.

> >
> > I can't think of anything other than this that the ofbiz framework
> > provides that grails doesn't.
> >
> > Cheers,
> >
> > Chris
> >

[Scott Gray-2]

Hi Chris

With all due respect, your desire to replace the entity engine with hibernate exhibits a serious lack of understanding of one of OFBiz's core design philosophies.  This has been discussed many times so I don't want to rehash the debate here but I do strongly suggest that you search the mailing lists for discussions pertaining to hibernate and ORM in general.

Regards
Scott

HotWax Media
http://www.hotwaxmedia.com

On 26/02/2010, at 8:32 AM, Christopher Snow wrote:

> Hi Jacques,
>
> Thanks for the comments.
>
> Not sure how grails handles extension of artifacts (except that Controllers and Services are classes so theoretically could be extended).
>
> Grails only needs to be restarted when the hibernate definitions have changed (I think). Controller and Service changes are dynamically reloaded in development mode without a restart.
>
> Grails has:  |"grails create-app helloworld" which is the equivalent of creating an ofbiz component.
>
> In ofbiz, I always have to jump into the ofbiz code, even if its just to configure it (e.g. data sources).  In grails, the component configuration is done in the component itself.  I would never expect you to modify the core grails code and create patches to ship with your application - this is a big disadvantage with ofbiz.
>
> Please don't think I'm giving ofbiz a hard time.  Don't forget, I'm interested in creating a standalone ofbiz framework (which would be especially useful for my current government client), but I'm not sure that the framework on it's own carrys any benefits compared to grails.  It's the business applications that give ofbiz the most advantage.
>
> Cheers,
>
> Chris
> |
>
> Jacques Le Roux wrote:
>> And one of the most important thing but not obvious in OFBiz,  extension and reutilisation of artifacts.
>> From hot-deploy, you can build your own applicaiton based on the trunk (or release but I'd recommend trunk for easier update later) without touching much of OFBiz itself. If you handle it right you may end with a couple of small patches. There are even small tools around, see ant - p, to deal with hat. This is where is the real OFBiz expertise, it takes some time to understand and use...
>> Also OFBiz is *great* when it comes to *not* compile, reboot, compile, reboot, compile, reboot, compile, reboot, compile, reboot, compile, reboot, OK you see...
>>
>> Jacques
>>
>> From: "Ruth Hoffman" <[hidden email]>
>>
>>
>>> Hi Jacopo:
>>>
>>> IMO, one should always give positive affirmations when responding to posts like these. OFBiz has plenty of great things we can say that shouldn't require much effort on your part to comment on:
>>>
>>> How about the seamless and transparent database support by way of the Entity Engine?  If you want to develop an application or implement ERP, then you don't need to worry about the database. You don't need to stress over whether to use Hiberanate or JDO or native SQL or whatever the latest database technology fad happens to be. The EE is here, its proven and best of all I don't have to deal with it! I can get on to developing my applications.
>>>
>>> Or the really cool Service Engine that lets me write reusable code. Java or otherwise!
>>>
>>> Or all the framework tools that have been integrated and proven. Everything from Internationalization and localization support to XML document handling. (Personally, I'm tired of having to integrate XML parsers every time I need that functionality in an application.)
>>>
>>> How hard is it to list some of these features? Take the "high road".
>>>
>>> Ruth
>>>
>>>
>>>
>>> Jacopo Cappellato wrote:
>>>> On Feb 26, 2010, at 2:27 PM, Christopher Snow wrote:
>>>>
>>>>
>>>>> Hey come on Jacopo - overall I'm actually trying to promote the use of ofbiz.  I've invested a considerable amount of time in it.
>>>>>
>>>>> I was hoping that my question would get ofbiz supporters to list some of the benefits of ofbiz over grails.
>>>>>
>>>>>
>>>>
>>>> Eh eh... this time your attempt will not help you to get easy information (at least from me): you will have to do your own research :-)
>>>>
>>>> Jacopo
>>>>
>>>>
>>>>
>>>>> Jacopo Cappellato wrote:
>>>>>
>>>>>> On Feb 26, 2010, at 1:20 PM, Christopher Snow wrote:
>>>>>>
>>>>>>
>>>>>>>> I can't think of anything other than this that the ofbiz framework provides that grails doesn't.
>>>>>>>>
>>>>>> If you are blind, all you can see is darkness.
>>>>>>
>>>>>> Jacopo
>>>>>>
>>>>>>
>>>>
>>>>
>>>>
>>>
>>
>>
>

[Chris Snow-3]

.. and grails has many plugins : jBPM, drools, birt, quartz, rest, soap,
etc that facilitate building enterprise systems.

[hidden email] wrote:

> Please see inline...
>
> On Fri, 2010-02-26 at 12:20 +0000, Christopher Snow wrote:
>  
>> One more - inline...
>>
>> Christopher Snow wrote:
>>    
>>> Hi Miles,
>>>
>>> I'm currently doing some work on making a standalone ofbiz development
>>> framework (i.e. no business functionality).  Your questions have got
>>> me thinking:
>>>
>>>      
> Interesting work. Will future OFBIZ official release based on this
> framework? Is there any preview working code in repository now?
>
>  
>>>   "what does the ofbiz framework give you that the grails framework
>>> doesn't?"
>>>      
>
> Yes. That's why I've started this topic. Since someone is dedicated in
> inventing wheel and do well, why OFBIZ keep home-made one?
> Consider the maintenance effort you are currently spending. And consider
> if OFBIZ will last another decade (I really hope so), how many effort
> will spend in keeping OFBIZ catch on the new technology evolve, like
> recently mentioned OSGi, etc...
>
>  
>>> A possible answer:
>>>
>>>   "Ofbiz gives you a ready made layout for backend management UI (i.e.
>>> screens, menus, forms)"
>>>      
>
> Beg me to argue that This is a higher UI level functionality. Grails has
> also its way to do UI-level component composition, based on decoration
> pattern. For the real problem, see next section.
>
>  
>> the ofbiz framework will give you an easy upgrade path to the full ofbiz
>> and all its business functionality.
>>    
> Yes, this is the first class factor. Although to write a new component
> in Grails is trival, to provide the new Grails code all/most ability to
> access the current OFBIZ business functionality and integrated it into
> the current OFBIZ framework is really a big challenge. The problem
> exists on every tier: persistence entity, service/event, widget. In
> every tier OFBIZ has its unique implementation technology and OFBIZ
> components seems to coupling on every tier, a little tight coupling, I
> think.
>
>  
>>> I can't think of anything other than this that the ofbiz framework
>>> provides that grails doesn't.
>>>
>>> Cheers,
>>>
>>> Chris
>>>
>>>      
>
>
>  

[Chris Snow-3]

There's a set of instructions at:

http://cwiki.apache.org/confluence/x/nYTW

Or I can send you a in progress hack of my latest attempt - it's 90mb.

> Interesting work. Will future OFBIZ official release based on this
> framework? Is there any preview working code in repository now?
>
>  

[Miles Huang]

On Fri, 2010-02-26 at 09:06 -0500, Ruth Hoffman wrote:

> How about the seamless and transparent database support by way of the
> Entity Engine?  If you want to develop an application or implement
> ERP,
> then you don't need to worry about the database. You don't need to
> stress over whether to use Hiberanate or JDO or native SQL or
> whatever
> the latest database technology fad happens to be. The EE is here, its
> proven and best of all I don't have to deal with it! I can get on to
> developing my applications.
>

I'm sorry to say this is also a Grails built in feature. Grails can
simply write the domain model as a Groovy bean. Just give a really
feature rich and yet simple example:
class Person {
  String pid
  String firstName
  String lastName
  BigDecimal salary
  Date birthday
  String notes

  static constraints = {
     pid(blank:false, unique: true)
     firstName(blank:false)
     lastName(blank:false)
     notes(blank:true, nullable:true, maxSize:5000)
  }

}
This is all the code you need to write to define a entity model, then
CRUD methods, nearly every possible simple finder methods (up to 2
fields composite criteria), auto SQL table DML maintenance with re-sync
ability on every time you change the model, are all ready for you. You
can also add some constraints for validation logic and storage hint
(most have default value so you don't need to code for every one), just
declaration, that's enough.
Constraints check are available on presentation/service/persistence
tier. Quite like OFBIZ entity engine, but more coding efficient, isn't
it?
And the sophisticated model relation management and auto
optimized-locking mechanism, which seems to be a weak point of OFBIZ
entity engine.

> Or all the framework tools that have been integrated and proven.
> Everything from Internationalization and localization support to XML
> document handling. (Personally, I'm tired of having to integrate XML
> parsers every time I need that functionality in an application.)
>
>
XML process, persistence, i18n support, are all readily built in Grails
platform.

[Miles Huang]

Grails can also provides these ability, which is the fundamental spirit
of "Rails" development environment, namely RoR, Grails.

On Fri, 2010-02-26 at 15:34 +0100, Jacques Le Roux wrote:
> Also OFBiz is *great* when it comes to *not* compile, reboot, compile,
> reboot, compile, reboot, compile, reboot, compile, reboot,
> compile, reboot, OK you see...
>
>

[Miles Huang]

Use Grails doesn't means bundle with Hibernate. Grails also supports
GORM-JPA combine, license compatible products such as OpenJPA can be
used instead. It can defer to the deploy time (thus up to end user) to
choose Hibernate or some other JPA implementation.

On Fri, 2010-02-26 at 09:00 -0700, Scott Gray wrote:

> Hi Chris
>
> With all due respect, your desire to replace the entity engine with hibernate exhibits a serious lack of understanding of one of OFBiz's core design philosophies.  This has been discussed many times so I don't want to rehash the debate here but I do strongly suggest that you search the mailing lists for discussions pertaining to hibernate and ORM in general.
>
> Regards
> Scott
>
> HotWax Media
> http://www.hotwaxmedia.com
>

[Scott Gray-2]

My point still stands, OFBiz intentionally does not use an ORM layer and if the reasons behind that are not understood then any discussions about it are going to be somewhat fruitless.

Regards
Scott

On 26/02/2010, at 10:06 AM, [hidden email] wrote:

> Use Grails doesn't means bundle with Hibernate. Grails also supports
> GORM-JPA combine, license compatible products such as OpenJPA can be
> used instead. It can defer to the deploy time (thus up to end user) to
> choose Hibernate or some other JPA implementation.
>
> On Fri, 2010-02-26 at 09:00 -0700, Scott Gray wrote:
>> Hi Chris
>>
>> With all due respect, your desire to replace the entity engine with hibernate exhibits a serious lack of understanding of one of OFBiz's core design philosophies.  This has been discussed many times so I don't want to rehash the debate here but I do strongly suggest that you search the mailing lists for discussions pertaining to hibernate and ORM in general.
>>
>> Regards
>> Scott
>>
>> HotWax Media
>> http://www.hotwaxmedia.com
>>
>
>

[BJ Freeman]

[hidden email] sent the following on 2/26/2010 8:45 AM:

> On Fri, 2010-02-26 at 09:06 -0500, Ruth Hoffman wrote:
>> How about the seamless and transparent database support by way of the
>> Entity Engine?  If you want to develop an application or implement
>> ERP,
>> then you don't need to worry about the database. You don't need to
>> stress over whether to use Hiberanate or JDO or native SQL or
>> whatever
>> the latest database technology fad happens to be. The EE is here, its
>> proven and best of all I don't have to deal with it! I can get on to
>> developing my applications.
>>
> I'm sorry to say this is also a Grails built in feature. Grails can
> simply write the domain model as a Groovy bean. Just give a really
> feature rich and yet simple example:
> class Person {
>   String pid
>   String firstName
>   String lastName
>   BigDecimal salary
>   Date birthday
>   String notes
>
>   static constraints = {
>      pid(blank:false, unique: true)
>      firstName(blank:false)
>      lastName(blank:false)
>      notes(blank:true, nullable:true, maxSize:5000)
>   }
>
> }
> This is all the code you need to write to define a entity model, then
> CRUD methods, nearly every possible simple finder methods (up to 2

Actually once you define the enity, CRUD is atomatically genterated.

> fields composite criteria), auto SQL table DML maintenance with re-sync
what you call re-sync is done at restart of ofbiz
> ability on every time you change the model, are all ready for you. You
> can also add some constraints for validation logic and storage hint
> (most have default value so you don't need to code for every one), just
> declaration, that's enough.
how is that different than ofbiz which also updates the UI with changes
to the entity.
> Constraints check are available on presentation/service/persistence
> tier. Quite like OFBIZ entity engine, but more coding efficient, isn't
> it?
using the mini language is more efficient.

> And the sophisticated model relation management and auto
> optimized-locking mechanism, which seems to be a weak point of OFBIZ
> entity engine.
>
>> Or all the framework tools that have been integrated and proven.
>> Everything from Internationalization and localization support to XML
>> document handling. (Personally, I'm tired of having to integrate XML
>> parsers every time I need that functionality in an application.)
how is that different than ofbiz?
>>
>>
> XML process, persistence, i18n support, are all readily built in Grails
> platform.
again how is that different than ofbiz other than how it is accomplished?
>
>

[David E. Jones-2]

There is even a term for this: object-relational impedance mismatch.

Of course, that is true for many other things, like object-service impedance mismatch, object-XML impedance mismatch, etc, etc. It comes down to the simple idea that modeling everything as a custom object is full of problems.

I agree Scott, this is definitely something worth researching for those into building enterprise systems.

-David


On Feb 26, 2010, at 10:13 AM, Scott Gray wrote:

> My point still stands, OFBiz intentionally does not use an ORM layer and if the reasons behind that are not understood then any discussions about it are going to be somewhat fruitless.
>
> Regards
> Scott
>
> On 26/02/2010, at 10:06 AM, [hidden email] wrote:
>
>> Use Grails doesn't means bundle with Hibernate. Grails also supports
>> GORM-JPA combine, license compatible products such as OpenJPA can be
>> used instead. It can defer to the deploy time (thus up to end user) to
>> choose Hibernate or some other JPA implementation.
>>
>> On Fri, 2010-02-26 at 09:00 -0700, Scott Gray wrote:
>>> Hi Chris
>>>
>>> With all due respect, your desire to replace the entity engine with hibernate exhibits a serious lack of understanding of one of OFBiz's core design philosophies.  This has been discussed many times so I don't want to rehash the debate here but I do strongly suggest that you search the mailing lists for discussions pertaining to hibernate and ORM in general.
>>>
>>> Regards
>>> Scott
>>>
>>> HotWax Media
>>> http://www.hotwaxmedia.com
>>>
>>
>>
>

[Ruth Hoffman-2]

Cool! Who knew.

Still, in OFBiz I don't even have to write the Person class. Its already
there. I don't even need to find a database and load the schema. All
that happens for me transparently. If I let it.

Ruth


[hidden email] wrote:

> On Fri, 2010-02-26 at 09:06 -0500, Ruth Hoffman wrote:
>  
>> How about the seamless and transparent database support by way of the
>> Entity Engine?  If you want to develop an application or implement
>> ERP,
>> then you don't need to worry about the database. You don't need to
>> stress over whether to use Hiberanate or JDO or native SQL or
>> whatever
>> the latest database technology fad happens to be. The EE is here, its
>> proven and best of all I don't have to deal with it! I can get on to
>> developing my applications.
>>
>>    
> I'm sorry to say this is also a Grails built in feature. Grails can
> simply write the domain model as a Groovy bean. Just give a really
> feature rich and yet simple example:
> class Person {
>   String pid
>   String firstName
>   String lastName
>   BigDecimal salary
>   Date birthday
>   String notes
>
>   static constraints = {
>      pid(blank:false, unique: true)
>      firstName(blank:false)
>      lastName(blank:false)
>      notes(blank:true, nullable:true, maxSize:5000)
>   }
>
> }
> This is all the code you need to write to define a entity model, then
> CRUD methods, nearly every possible simple finder methods (up to 2
> fields composite criteria), auto SQL table DML maintenance with re-sync
> ability on every time you change the model, are all ready for you. You
> can also add some constraints for validation logic and storage hint
> (most have default value so you don't need to code for every one), just
> declaration, that's enough.
> Constraints check are available on presentation/service/persistence
> tier. Quite like OFBIZ entity engine, but more coding efficient, isn't
> it?
> And the sophisticated model relation management and auto
> optimized-locking mechanism, which seems to be a weak point of OFBIZ
> entity engine.
>
>  
>> Or all the framework tools that have been integrated and proven.
>> Everything from Internationalization and localization support to XML
>> document handling. (Personally, I'm tired of having to integrate XML
>> parsers every time I need that functionality in an application.)
>>
>>
>>    
> XML process, persistence, i18n support, are all readily built in Grails
> platform.
>
>
>  

[BJ Freeman]

The only thing I see differet about grails is it use ROR. There was some
integration of ROR in ofbiz but the motivator has since stopped and no
more effort has been done. check out Davids response
http://www.mail-archive.com/ofbiz-dev@.../msg01688.html

maybe picking up where that left off would be the best implantations step.

[hidden email] sent the following on 2/26/2010 8:49 AM:

> Grails can also provides these ability, which is the fundamental spirit
> of "Rails" development environment, namely RoR, Grails.
>
> On Fri, 2010-02-26 at 15:34 +0100, Jacques Le Roux wrote:
>> Also OFBiz is *great* when it comes to *not* compile, reboot, compile,
>> reboot, compile, reboot, compile, reboot, compile, reboot,
>> compile, reboot, OK you see...
>>
>>
>
>

[Miles Huang]

On Fri, 2010-02-26 at 09:22 -0800, BJ Freeman wrote:

>
> [hidden email] sent the following on 2/26/2010 8:45 AM:
> > On Fri, 2010-02-26 at 09:06 -0500, Ruth Hoffman wrote:
> >> How about the seamless and transparent database support by way of the
> >> Entity Engine?  If you want to develop an application or implement
> >> ERP,
> >> then you don't need to worry about the database. You don't need to
> >> stress over whether to use Hiberanate or JDO or native SQL or
> >> whatever
> >> the latest database technology fad happens to be. The EE is here, its
> >> proven and best of all I don't have to deal with it! I can get on to
> >> developing my applications.
> >>
> > I'm sorry to say this is also a Grails built in feature. Grails can
> > simply write the domain model as a Groovy bean. Just give a really
> > feature rich and yet simple example:
> > class Person {
> >   String pid
> >   String firstName
> >   String lastName
> >   BigDecimal salary
> >   Date birthday
> >   String notes
> >
> >   static constraints = {
> >      pid(blank:false, unique: true)
> >      firstName(blank:false)
> >      lastName(blank:false)
> >      notes(blank:true, nullable:true, maxSize:5000)
> >   }
> >
> > }
> > This is all the code you need to write to define a entity model, then
> > CRUD methods, nearly every possible simple finder methods (up to 2
> Actually once you define the enity, CRUD is atomatically genterated.
>
> > fields composite criteria), auto SQL table DML maintenance with re-sync
> what you call re-sync is done at restart of ofbiz
> > ability on every time you change the model, are all ready for you. You
> > can also add some constraints for validation logic and storage hint
> > (most have default value so you don't need to code for every one), just
> > declaration, that's enough.
> how is that different than ofbiz which also updates the UI with changes
> to the entity.

Sorry I haven't mentioned this. Grails scaffolding mechanism can
generate UI based on the domain model define, with validation, and
reflect the changes if you have made.


> > Constraints check are available on presentation/service/persistence
> > tier. Quite like OFBIZ entity engine, but more coding efficient, isn't
> > it?
> using the mini language is more efficient.
>
I haven't touch much of the mini-lang part yet. What I've demoed is the
equivalence of the OFBIZ entity definition XML plus validation code
written in mini-lang events.

> > And the sophisticated model relation management and auto
> > optimized-locking mechanism, which seems to be a weak point of OFBIZ
> > entity engine.
> >
> >> Or all the framework tools that have been integrated and proven.
> >> Everything from Internationalization and localization support to XML
> >> document handling. (Personally, I'm tired of having to integrate XML
> >> parsers every time I need that functionality in an application.)
> how is that different than ofbiz?
> >>
> >>
> > XML process, persistence, i18n support, are all readily built in Grails
> > platform.
> again how is that different than ofbiz other than how it is accomplished?
> >
> >

I'm only try following the question and answer of Christopher has raised:
"I was hoping that my question would get ofbiz supporters to list some of
the benefits of ofbiz over grails." So sorry no much "grails over ofbiz"
here ;-)

[rajsaini]

I tried the OSGi thing but it was not possible to deploy each
application as OSGi bundle. Instead I could create single bundle and run
the OFBiz minimal container as OSGi bundle.

Creating OSGi bundle for each application will be great. This is
certainly the way forward to create modular OFBiz. I hope to work
further on this very soon.

You can find a bit more about OFBiz OSGi at
http://sourceforge.net/projects/ofbiz-osgi/

Thanks,

Raj

Jacques Le Roux wrote:

> Chris,
>
> I agree that OSGI would be a better option than Grail. And yes, you
> put some good cards on the table, but... challenging isn'it ?
> If we succeed in removing components dependencies and take the time to
> think well about it, then why not?
>
> Jacques
>
> From: "Christopher Snow" <[hidden email]>
>> I like developing with ofbiz, but it is very cumbersome compared to
>> developing with grails. I have even started creating some prototypes
>> in grails to get some idea of what would be required to implement
>> ofbiz in grails.
>>
>> Personaly, I don't think grails is suitable for building large
>> applications like ofbiz. The business components would have to be
>> either separated by directory structure within grails, or by creating
>> a separate grails application for each component and using something
>> like spring integration or web services for wiring the applications
>> together. Either way, modularity is an issue.
>>
>> I've even looked at doing the same in JBoss seam. The same problem as
>> grails with modularity.
>>
>> Some other thoughts...
>>
>> The more I learn about OSGi, the more that I think this is the way
>> forward for modularity.
>> Hibernate or JPA for persistence, although I think an application
>> dictionary approach like Adempiere would reduce hand coding
>> dramatically.
>> jBPM could be used for the business services. This would have two
>> advantages, GUI tools for business users, automatic documentation of
>> the services.
>> Perhaps even Flex and BlazeDS for the front end. This gives thick
>> client functionality in a thin client.
>>
>>
>>
>> Miles Huang wrote:
>>> Hi OFBIZ users and developers,
>>>
>>>   First of all, I'm a novice of OFBIZ. I've just started to learn
>>> and use it
>>> for a couple of month. So if I have made some mistake in the
>>> following post,
>>> criticisms are welcomed :clap:
>>>
>>>   Does anyone using OFBIZ interested in porting OFBIZ to leverage a
>>> mature
>>> and decent web platform, more specifically Grails?
>>>
>>>   The idea comes from the post from Christopher Snow, "There was some
>>> interest in porting openerp to jython", and the recent hot topic
>>> "groovy
>>> service code instead of minilang". Excuse me, I'm going a step
>>> further.:-P
>>>
>>>   The problem an OFBIZ novice commonly facing is when he/she has to go
>>> further than the OFBIZ OOTB functionality ( which proves he/she is
>>> becoming
>>> a really OFBIZ user:drunk: ). He/she have to learn a lot of
>>> techniques in
>>> the unique OFBIZ way, which is commonly a well defined web
>>> framework/OR-mapping tool should take care. This make learning-curve
>>> steep.
>>> I fully understand the historical reason of OBFIZ, such as OFBIZ
>>> utilize the
>>> IoC idea earlier than Spring, entity-engine evolution over EJB2, and
>>> the
>>> ability to avoid the compile-deploy-test cycle and make development
>>> more
>>> efficient. And I really admire them, especially considering the age
>>> when
>>> OFBIZ developers invent them. But these are not unique features of
>>> OFBIZ now
>>> a days. Leading web development platforms such as RoR and Grails has
>>> go much
>>> further than what OFBIZ's technical platform can provide, since they
>>> have
>>> dedicated man power to spend in researching these area.
>>>
>>>   What make things worse is many ways to accomplish same goal in
>>> OFBIZ. xml
>>> mini-lang, groovy, bsh, java, just named some. It giving developers
>>> freedom
>>> to choose technology what they like, sounds good. But it is a different
>>> story for the long term platform maintainers and customizers. With
>>> adequate
>>> open practice, can we gain enough experience to concentrate on a
>>> consistent
>>> way to do development task in OFBIZ? (To make me clear, I'm not
>>> advocating a
>>> single programming language to solve any problem).
>>>
>>>   So..., why I'm still interested in OFBIZ? I must admit even with the
>>> complains, I'm still an OFBIZ fans till now. The answer is the business
>>> level functionalities. This is the real strength of OFBIZ.
>>>
>>>   Since most services and actions have implemented in groovy/Java,
>>> porting
>>> these code to Grails are smooth. With the leverage of Groovy DSL over
>>> mini-lang, we will go further. Theoretically the chance to migrate
>>> the whole
>>> OFBIZ package to Grails platform are possible (more serious research
>>> work
>>> needs to be done in this area), while keeping the strength of OFBIZ
>>> - the
>>> business level assets accumulated in years.
>>>
>>>   Of course it will not be an easy step, only great gains worth such
>>> huge
>>> change. So what we may gain from the transition:
>>> * Faster development speed - more efficient, on-rails level;
>>> * Less code - less maintenance spend;
>>> * More concentrate - No more re-invent wheel. Let's concentrate on what
>>> makes OFBIZ unique and leading-edge in limited resource;
>>> * More 3rd party software integration ability - provided by the Grails
>>> platform and plenty of plugins;
>>> * Easier deployment - no more embedding Tomcat, just standard war
>>> packages,
>>> which is deployable to any container, even cloud computing providers;
>>> * Last but not least, more smooth learning curve - the key factor to
>>> gain
>>> more new coming user and make success.
>>>
>>>   Is this a right way to the future? Any thoughts?
>>>
>>> Regards,
>>> Miles.
>>>  
>>
>
>