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

[Chris Snow-3]

Hi Raj,

Why was it not possible to deploy each application as an OSGi bundle?

Many thanks,

Chris

Raj Saini wrote:

> 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.
>>>>  
>>>
>>
>>
>

[BJ Freeman]

just a note you might ask for a vote or make a jira about your idea, if
you expect to have it included in the trunk version.
You may have to end up supporting this yourself.

Raj Saini sent the following on 2/28/2010 4:26 AM:

> 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.
>>>>  
>>>
>>
>>
>
>

[rajsaini]

Hi Chris,

It is because of the dependencies. Framework depends on applications and
applications on framework. Even with the the framework, there was a
dependency of entity engine depending on the service. I really wanted to
create separate bundles for framework components such as entity engine,
service engine, security, Geronimo etc. IIRC, problem was with entity
engine depending service engine due to some other component ( I think
securityext).

Thanks,

Raj
Christopher Snow wrote:

> Hi Raj,
>
> Why was it not possible to deploy each application as an OSGi bundle?
>
> Many thanks,
>
> Chris
>
> Raj Saini wrote:
>> 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.
>>>>>  
>>>>
>>>
>>>
>>
>
>

[Chris Snow-3]

Hi Raj,

Yesterday I managed to get a standalone entity engine + catalina running.
it should be possible to even remove catalina - I only used it so that I
could create a small web app to interact with the entity engine.  The
framework folders I used were:

- start
- base
- entity
- geronimo (requied for transactions)
- catalina
- entityext (may be possible to remove this)

I think it should be possible to make a osgi bundle of the entity engine
without catalina.

I will post a page on the wiki documenting my steps.

Cheers,

Chris

> Hi Chris,
>
> It is because of the dependencies. Framework depends on applications and
> applications on framework. Even with the the framework, there was a
> dependency of entity engine depending on the service. I really wanted to
> create separate bundles for framework components such as entity engine,
> service engine, security, Geronimo etc. IIRC, problem was with entity
> engine depending service engine due to some other component ( I think
> securityext).
>
> Thanks,
>
> Raj
> Christopher Snow wrote:
>> Hi Raj,
>>
>> Why was it not possible to deploy each application as an OSGi bundle?
>>
>> Many thanks,
>>
>> Chris
>>
>> Raj Saini wrote:
>>> 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.
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>
>
>

--
Chris Snow - CEng MBCS CITP MBA (Tech Mgmt) (Open) CISSP

Tel: [phone]
Mob: [phone]
Www: www.snowconsulting.co.uk

[Chris Snow-3]

I forgot the sql folder in the list!

> Hi Raj,
>
> Yesterday I managed to get a standalone entity engine + catalina running.
> it should be possible to even remove catalina - I only used it so that I
> could create a small web app to interact with the entity engine.  The
> framework folders I used were:
>
> - start
> - base
> - entity
> - geronimo (requied for transactions)
> - catalina
> - entityext (may be possible to remove this)
>
> I think it should be possible to make a osgi bundle of the entity engine
> without catalina.
>
> I will post a page on the wiki documenting my steps.
>
> Cheers,
>
> Chris
>
>> Hi Chris,
>>
>> It is because of the dependencies. Framework depends on applications and
>> applications on framework. Even with the the framework, there was a
>> dependency of entity engine depending on the service. I really wanted to
>> create separate bundles for framework components such as entity engine,
>> service engine, security, Geronimo etc. IIRC, problem was with entity
>> engine depending service engine due to some other component ( I think
>> securityext).
>>
>> Thanks,
>>
>> Raj
>> Christopher Snow wrote:
>>> Hi Raj,
>>>
>>> Why was it not possible to deploy each application as an OSGi bundle?
>>>
>>> Many thanks,
>>>
>>> Chris
>>>
>>> Raj Saini wrote:
>>>> 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.
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>>
>>
>
>
> --
> Chris Snow - CEng MBCS CITP MBA (Tech Mgmt) (Open) CISSP
>
> Tel: [phone]
> Mob: [phone]
> Www: www.snowconsulting.co.uk
>
>

--
Chris Snow - CEng MBCS CITP MBA (Tech Mgmt) (Open) CISSP

Tel: [phone]
Mob: [phone]
Www: www.snowconsulting.co.uk

[rajsaini]

Hi Chris,

Did you do any changes in the OFBiz code? entityext can be a problem as
last time I checked it was dependent on service engine. I will work on
it during the weekend and report my findings.

Thanks,

Raj

Chris Snow wrote:

> I forgot the sql folder in the list!
>
>  
>> Hi Raj,
>>
>> Yesterday I managed to get a standalone entity engine + catalina running.
>> it should be possible to even remove catalina - I only used it so that I
>> could create a small web app to interact with the entity engine.  The
>> framework folders I used were:
>>
>> - start
>> - base
>> - entity
>> - geronimo (requied for transactions)
>> - catalina
>> - entityext (may be possible to remove this)
>>
>> I think it should be possible to make a osgi bundle of the entity engine
>> without catalina.
>>
>> I will post a page on the wiki documenting my steps.
>>
>> Cheers,
>>
>> Chris
>>
>>    
>>> Hi Chris,
>>>
>>> It is because of the dependencies. Framework depends on applications and
>>> applications on framework. Even with the the framework, there was a
>>> dependency of entity engine depending on the service. I really wanted to
>>> create separate bundles for framework components such as entity engine,
>>> service engine, security, Geronimo etc. IIRC, problem was with entity
>>> engine depending service engine due to some other component ( I think
>>> securityext).
>>>
>>> Thanks,
>>>
>>> Raj
>>> Christopher Snow wrote:
>>>      
>>>> Hi Raj,
>>>>
>>>> Why was it not possible to deploy each application as an OSGi bundle?
>>>>
>>>> Many thanks,
>>>>
>>>> Chris
>>>>
>>>> Raj Saini wrote:
>>>>        
>>>>> 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.
>>>>>>>>
>>>>>>>>                
>>>>>>            
>>>>        
>>>
>>>      
>> --
>> Chris Snow - CEng MBCS CITP MBA (Tech Mgmt) (Open) CISSP
>>
>> Tel: [phone]
>> Mob: [phone]
>> Www: www.snowconsulting.co.uk
>>
>>
>>    
>
>
>  

[Chris Snow-3]

Hi Raj,

I didn't need entityext.  I documented my findings here:
http://cwiki.apache.org/confluence/x/zQDi

I had also started working on completely separating the entity engine
from the ofbiz "container".  This should be possible too with a bit more
effort.  As a first step towards OSGi, I was thinking of using spring to
inject in the necessary resources (entityengine.xml, xx/entitymodel.xml).

Cheers,

Chris

Raj Saini wrote:

> Hi Chris,
>
> Did you do any changes in the OFBiz code? entityext can be a problem
> as last time I checked it was dependent on service engine. I will work
> on it during the weekend and report my findings.
>
> Thanks,
>
> Raj
>
> Chris Snow wrote:
>> I forgot the sql folder in the list!
>>
>>  
>>> Hi Raj,
>>>
>>> Yesterday I managed to get a standalone entity engine + catalina
>>> running.
>>> it should be possible to even remove catalina - I only used it so
>>> that I
>>> could create a small web app to interact with the entity engine.  The
>>> framework folders I used were:
>>>
>>> - start
>>> - base
>>> - entity
>>> - geronimo (requied for transactions)
>>> - catalina
>>> - entityext (may be possible to remove this)
>>>
>>> I think it should be possible to make a osgi bundle of the entity
>>> engine
>>> without catalina.
>>>
>>> I will post a page on the wiki documenting my steps.
>>>
>>> Cheers,
>>>
>>> Chris
>>>
>>>    
>>>> Hi Chris,
>>>>
>>>> It is because of the dependencies. Framework depends on
>>>> applications and
>>>> applications on framework. Even with the the framework, there was a
>>>> dependency of entity engine depending on the service. I really
>>>> wanted to
>>>> create separate bundles for framework components such as entity
>>>> engine,
>>>> service engine, security, Geronimo etc. IIRC, problem was with entity
>>>> engine depending service engine due to some other component ( I think
>>>> securityext).
>>>>
>>>> Thanks,
>>>>
>>>> Raj
>>>> Christopher Snow wrote:
>>>>      
>>>>> Hi Raj,
>>>>>
>>>>> Why was it not possible to deploy each application as an OSGi bundle?
>>>>>
>>>>> Many thanks,
>>>>>
>>>>> Chris
>>>>>
>>>>> Raj Saini wrote:
>>>>>        
>>>>>> 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.
>>>>>>>>>
>>>>>>>>>                
>>>>>>>            
>>>>>        
>>>>
>>>>      
>>> --
>>> Chris Snow - CEng MBCS CITP MBA (Tech Mgmt) (Open) CISSP
>>>
>>> Tel: [phone]
>>> Mob: [phone]
>>> Www: www.snowconsulting.co.uk
>>>
>>>
>>>    
>>
>>
>>  
>

[rajsaini]

Thanks Chris,

I will look at the page.

Spring has some thing called Dynamic Modules for OSGi. Dynamic services
are part of the OSGi specs now. It should be possible to use either of them.

Thanks,

Raj
 
Christopher Snow wrote:

> Hi Raj,
>
> I didn't need entityext.  I documented my findings here:
> http://cwiki.apache.org/confluence/x/zQDi
>
> I had also started working on completely separating the entity engine
> from the ofbiz "container".  This should be possible too with a bit
> more effort.  As a first step towards OSGi, I was thinking of using
> spring to inject in the necessary resources (entityengine.xml,
> xx/entitymodel.xml).
>
> Cheers,
>
> Chris
>
> Raj Saini wrote:
>> Hi Chris,
>>
>> Did you do any changes in the OFBiz code? entityext can be a problem
>> as last time I checked it was dependent on service engine. I will
>> work on it during the weekend and report my findings.
>>
>> Thanks,
>>
>> Raj
>>
>> Chris Snow wrote:
>>> I forgot the sql folder in the list!
>>>
>>>  
>>>> Hi Raj,
>>>>
>>>> Yesterday I managed to get a standalone entity engine + catalina
>>>> running.
>>>> it should be possible to even remove catalina - I only used it so
>>>> that I
>>>> could create a small web app to interact with the entity engine.  The
>>>> framework folders I used were:
>>>>
>>>> - start
>>>> - base
>>>> - entity
>>>> - geronimo (requied for transactions)
>>>> - catalina
>>>> - entityext (may be possible to remove this)
>>>>
>>>> I think it should be possible to make a osgi bundle of the entity
>>>> engine
>>>> without catalina.
>>>>
>>>> I will post a page on the wiki documenting my steps.
>>>>
>>>> Cheers,
>>>>
>>>> Chris
>>>>
>>>>  
>>>>> Hi Chris,
>>>>>
>>>>> It is because of the dependencies. Framework depends on
>>>>> applications and
>>>>> applications on framework. Even with the the framework, there was a
>>>>> dependency of entity engine depending on the service. I really
>>>>> wanted to
>>>>> create separate bundles for framework components such as entity
>>>>> engine,
>>>>> service engine, security, Geronimo etc. IIRC, problem was with entity
>>>>> engine depending service engine due to some other component ( I think
>>>>> securityext).
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Raj
>>>>> Christopher Snow wrote:
>>>>>    
>>>>>> Hi Raj,
>>>>>>
>>>>>> Why was it not possible to deploy each application as an OSGi
>>>>>> bundle?
>>>>>>
>>>>>> Many thanks,
>>>>>>
>>>>>> Chris
>>>>>>
>>>>>> Raj Saini wrote:
>>>>>>      
>>>>>>> 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.
>>>>>>>>>>
>>>>>>>>>>                
>>>>>>>>            
>>>>>>        
>>>>>
>>>>>      
>>>> --
>>>> Chris Snow - CEng MBCS CITP MBA (Tech Mgmt) (Open) CISSP
>>>>
>>>> Tel: [phone]
>>>> Mob: [phone]
>>>> Www: www.snowconsulting.co.uk
>>>>
>>>>
>>>>    
>>>
>>>
>>>  
>>
>
>

[chris snow]

Hi Raj,

I have some questions / ideas regarding OSGi - shall we use your ofbiz-osgi forum on sourceforge for our discussions?

Many thanks,

Chris

[rajsaini]

Hi Chris,

I don't mind discussing it over there. However, I would prefer it here
if other community members do not have problem.

I have also been working on creating OSGi based standalone entity engine
and have been successful so far except one DelgatorFactory classloading.
This is classic OSGi problem and finding it difficult to resolve. I am
not sure if it is due to the DelegatorFactory service provider interface
or OSGi classic classloading problem. I will report my finding as soon
as I have solution.

Thanks,

Raj


chris snow wrote:
> Hi Raj,
>
> I have some questions / ideas regarding OSGi - shall we use your ofbiz-osgi
> forum on sourceforge for our discussions?
>
> Many thanks,
>
> Chris
>  

[Jacques Le Roux]

Also consider the new effort David is doing/leading on multi-tenants (I say that because I know there are implications on
Delegator...)

Jacques

From: "Raj Saini" <[hidden email]>

> Hi Chris,
>
> I don't mind discussing it over there. However, I would prefer it here if other community members do not have problem.
>
> I have also been working on creating OSGi based standalone entity engine and have been successful so far except one
> DelgatorFactory classloading. This is classic OSGi problem and finding it difficult to resolve. I am not sure if it is due to the
> DelegatorFactory service provider interface or OSGi classic classloading problem. I will report my finding as soon as I have
> solution.
>
> Thanks,
>
> Raj
>
>
> chris snow wrote:
>> Hi Raj,
>>
>> I have some questions / ideas regarding OSGi - shall we use your ofbiz-osgi
>> forum on sourceforge for our discussions?
>>
>> Many thanks,
>>
>> Chris
>>
>

[rajsaini]

Hi Chris,

I could manage to run OBFiz entity as OSGi. I have created separate OSGi
bundles for base, entity, start and geronimo components. However, due to
some circular dependencies, I had to merge base and geronimo with
entity. Now, it is possible to run the OFBiz minimal container on top of
Equinox OSGi kernel.

I will we working on creating a small application using entity engine
and OSGi embedded web container (Jetty). Using embedded web container
would allow to create web applications based on OFBiz using other
technologies such as JSF, Struts etc.

Thanks,

Raj

> Hi Raj,
>
> I have some questions / ideas regarding OSGi - shall we use your ofbiz-osgi
> forum on sourceforge for our discussions?
>
> Many thanks,
>
> Chris
>  

[chris snow-2]

Hi Raj, that's fantastic news. Do you have any code that I can play with?

On 9 Mar 2010 08:16, "Raj Saini" <[hidden email]> wrote:

Hi Chris,

I could manage to run OBFiz entity as OSGi. I have created separate OSGi
bundles for base, entity, start and geronimo components. However, due to
some circular dependencies, I had to merge base and geronimo with entity.
Now, it is possible to run the OFBiz minimal container on top of Equinox
OSGi kernel.

I will we working on creating a small application using entity engine and
OSGi embedded web container (Jetty). Using embedded web container would
allow to create web applications based on OFBiz using other technologies
such as JSF, Struts etc.

Thanks,

Raj



> Hi Raj,
>
> I have some questions / ideas regarding OSGi - shall we use your
ofbiz-osgi
> forum ...

[rajsaini]

Hi Chris,

There are couple of bundles. I will bundle them together in a zip and
upload it on sourceforge and let you know.

Thanks,

Raj

chris snow wrote:

> Hi Raj, that's fantastic news. Do you have any code that I can play with?
>
> On 9 Mar 2010 08:16, "Raj Saini" <[hidden email]> wrote:
>
> Hi Chris,
>
> I could manage to run OBFiz entity as OSGi. I have created separate OSGi
> bundles for base, entity, start and geronimo components. However, due to
> some circular dependencies, I had to merge base and geronimo with entity.
> Now, it is possible to run the OFBiz minimal container on top of Equinox
> OSGi kernel.
>
> I will we working on creating a small application using entity engine and
> OSGi embedded web container (Jetty). Using embedded web container would
> allow to create web applications based on OFBiz using other technologies
> such as JSF, Struts etc.
>
> Thanks,
>
> Raj
>
>
>
>  
>> Hi Raj,
>>
>> I have some questions / ideas regarding OSGi - shall we use your
>>    
> ofbiz-osgi
>  
>> forum ...
>>    
>
>