OFBiz › OFBiz - User

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

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

54 messages Options

123

Miles Huang

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

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

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.

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

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

Adrian Crum

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

Miles Huang wrote:
> 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

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

So we trade new users having to learn the OFBiz way for new users having
to learn the Grails way. What have we gained?

-Adrian

BJ Freeman

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

In reply to this post by Miles Huang

the porting usually refers to the UI, this can be handles but adding a
interface to ofbiz like has been done for others.

if that is what your proposing and want to put the energy in, then go
for it.

for instance I use swing and SWT.
but not many are interested so it stays in my svn for my customers.

Miles Huang sent the following on 2/24/2010 12:40 PM:

> 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

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

In reply to this post by Miles Huang

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:

Jacques Le Roux

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

Administrator

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

Miles Huang

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

In reply to this post by Adrian Crum

Just list some of the gains by different roles involved in the OFBIZ
ecosystem:

* For OFBIZ provider business owners and end-users:
As such a sophisticated business application, the training cost for new
comers is much high. The cost can be branched into 2 parts:
1) Learning the business model and logic implemented by OFBIZ
2) Learning OFBIZ's unique technical platform
The first part cost is no doubt value-able and unavoidable, because it's
closely related to the business and specific product.
But the second part is the cost that doesn't gain any direct benefits to
the business. So they like to find a way to cut down such cost. To find
a new developer familiar with Grails is much easier than find a new
developer familiar with OFBIZ platform, isn't it? The second part cost
can be cut down to 0 by hire a qualified developer.

* For NEW developers:
Assume the worst case, the new developers doesn't familiar either of
these technologies. Then he has 2 choices:
1) Spend 2 months to get familiar with the unique OFBIZ technical
platform, which may get the OFBIZ job done, but nothing else.
2) Spend 2 months to learn a technology like Grails, which can not only
solve the OFBIZ related requirements, but also suitable to solve a
wide-range of web development problems.
Which one do you think he/she would like to spend their time into?

* For current Experts:
They may need to learn a new technologies, but this is one-time cost.
After this, they can be released from the long-last technical platform
maintain task, concentrate on the core business issues.
Although I don't know them yet, I bet the maintainers of the OFBIZ
technical platform may have gathered a lot of improvement idea for the
core platform already, inspired by other leading platforms. But they
have limited time/effort to do so, or even just wondering: does it
worthwhile to re-invent the wheels?

-Miles

On Wed, 2010-02-24 at 13:03 -0800, Adrian Crum wrote:

> Miles Huang wrote:
> > 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
>
> > 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.
>
> So we trade new users having to learn the OFBiz way for new users having
> to learn the Grails way. What have we gained?
>
> -Adrian

Miles Huang

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

In reply to this post by Chris Snow-3

May be the Grails plugin mechanism is a good solution for the modularity problem. If we separate the OFBIZ components into stand-alone Grails plugins, each component is just like separated Grails applications, which can be maintained in their own source directory structure. And during development period, the Grails framework can provide sophisticated mechanisms to resolve the OFBIZ module dependency. At runtime, the dependent components are just deployed alongside with the referencing components in the same web application, remote service call is not required.

I'm not familiar with OSGi, so I can't say much about it. But if we need to support dynamical deploy/undeploy componets and multi-version module, the OSGi promise sounds attractive. Through a quick glance at the presentation from spring source ( OSGi 4.2 the Blueprint Service RI provider ), my understanding is the OSGi will take the responsibility to manage the web application dynamic module, while the web app framework such as Grails will take the responsibility to construct the dynamic module implementation framework. Does this mean OSGI and Grails technology can be integrated without overlaps and conflicts?

Chris Snow-3

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

Plugins could be used for separating the modules, this will be more
interesting in Grails 2.0 when the plugin framework will use OSGi -
http://jira.codehaus.org/browse/GRAILS-2221

Rather than bring ofbiz to grails, you may find it would be easier to
bring grails to ofbiz, for example it should be relatively trivial to
sit a grails app on top of ofbiz (i.e. as a war file), and use grails to
access the current ofbiz services.

Note that you can already use groovy for writing ofbiz services.
Eventually, when GSP gets separated from grails, this could be used in
ofbiz instead of ftl - http://jira.codehaus.org/browse/GRAILS-5657

Note that OpenTaps 1.5 (ofbiz derivative) uses hibernate for the
persistence layer instead of the home grown ofbiz ORM. It would be nice
to see an option like that in ofbiz!

Miles Huang wrote:

> May be the Grails plugin mechanism is a good solution for the modularity
> problem. If we separate the OFBIZ components into stand-alone Grails
> plugins, each component is just like separated Grails applications, which
> can be maintained in their own source directory structure. And during
> development period, the Grails framework can provide sophisticated
> mechanisms to resolve the OFBIZ module dependency. At runtime, the dependent
> components are just deployed alongside with the referencing components in
> the same web application, remote service call is not required.
>
> I'm not familiar with OSGi, so I can't say much about it. But if we need to
> support dynamical deploy/undeploy componets and multi-version module, the
> OSGi promise sounds attractive. Through a quick glance at the presentation
> from spring source ( OSGi 4.2 the Blueprint Service RI provider ), my
> understanding is the OSGi will take the responsibility to manage the web
> application dynamic module, while the web app framework such as Grails will
> take the responsibility to construct the dynamic module implementation
> framework. Does this mean OSGI and Grails technology can be integrated
> without overlaps and conflicts?
>

Erwan de FERRIERES

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

Le 25/02/2010 14:31, Christopher Snow a écrit :

> Note that OpenTaps 1.5 (ofbiz derivative) uses hibernate for the
> persistence layer instead of the home grown ofbiz ORM. It would be nice
> to see an option like that in ofbiz!
>

Hi Chris,

Licenses are not compatible... we can't integrate Hibernate in OFBiz as
it is under a LGPL product (https://www.hibernate.org/356.html), see
http://www.apache.org/legal/resolved.html#category-x

It's the same reason cobertura is not included, or selenium-server...

Cheers,

--
Erwan de FERRIERES
www.nereide.biz

Miles Huang

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

In reply to this post by Chris Snow-3

On Thu, 2010-02-25 at 05:31 -0800, Chris Snow-2 [via OFBiz] wrote:
> Plugins could be used for separating the modules, this will be more
> interesting in Grails 2.0 when the plugin framework will use OSGi -
> http://jira.codehaus.org/browse/GRAILS-2221
>

This is a good side witness on the correctness of "Don't re-invent
wheels". Would it be nice to upgrade a 3rd-party library and sit-back,
then suddenly an excellent new feature bring in?

On Thu, 2010-02-25 at 05:31 -0800, Chris Snow-2 [via OFBiz] wrote:
> Rather than bring ofbiz to grails, you may find it would be easier to
> bring grails to ofbiz, for example it should be relatively trivial to
> sit a grails app on top of ofbiz (i.e. as a war file), and use grails
> to
> access the current ofbiz services.
>

Nice idea. Instead of move the whole platform to Grails as a huge step,
bring in Grails to OFBIZ, a reversed way could be an easier and more
acceptable choice. May be one or some components could be re-written in
Grails, while keep interoperability with other components.

When this could be done, more people can make judgement based on the
running code. And this bring in a gradational upgrade path.

David E. Jones-2

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

As with all other possible alternate technologies and practices, if you really like something the thing to do is a proof of concept project.

For a really simple project you could re-implement the example application on your preferred technology. That would at least be a starting point for comparison of the technologies and development approaches. Beyond that some parts of different apps could be built out to further demonstrate the superiority of the new tools.

Without that, I guess there really isn't much to discuss, and that's fine because also without that it's clear that no one really cares a whole lot about it (unless of course someone else does all the work!).

-David

On Feb 25, 2010, at 10:42 PM, Miles Huang wrote:

>
> On Thu, 2010-02-25 at 05:31 -0800, Chris Snow-2 [via OFBiz] wrote:
>> Plugins could be used for separating the modules, this will be more
>> interesting in Grails 2.0 when the plugin framework will use OSGi -
>> http://jira.codehaus.org/browse/GRAILS-2221
>>
>
> This is a good side witness on the correctness of "Don't re-invent
> wheels". Would it be nice to upgrade a 3rd-party library and sit-back,
> then suddenly an excellent new feature bring in?
>
>
> On Thu, 2010-02-25 at 05:31 -0800, Chris Snow-2 [via OFBiz] wrote:
>> Rather than bring ofbiz to grails, you may find it would be easier to
>> bring grails to ofbiz, for example it should be relatively trivial to
>> sit a grails app on top of ofbiz (i.e. as a war file), and use grails
>> to
>> access the current ofbiz services.
>>
>
> Nice idea. Instead of move the whole platform to Grails as a huge step,
> bring in Grails to OFBIZ, a reversed way could be an easier and more
> acceptable choice. May be one or some components could be re-written in
> Grails, while keep interoperability with other components.
>
> When this could be done, more people can make judgement based on the
> running code. And this bring in a gradational upgrade path.
>
>
>
>
> --
> View this message in context: http://n4.nabble.com/Brain-storm-OFBIZ-on-Grails-is-this-a-right-way-for-the-future-tp1568009p1570179.html
> Sent from the OFBiz - User mailing list archive at Nabble.com.

Jacques Le Roux

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

Administrator

In reply to this post by Miles Huang

Miles,

Well tried, from your argumentation I guess that

1) you certainly know Grail,
2) most of us don't,
3) you don't know much about OFBiz yet

So you try to push Grail and we brake on it. As David wisely suggested in another email a POC is the way for you now...

Thanks for you interest in OFBiz

Jacques

From: <[hidden email]>

> Just list some of the gains by different roles involved in the OFBIZ
> ecosystem:
>
> * For OFBIZ provider business owners and end-users:
> As such a sophisticated business application, the training cost for new
> comers is much high. The cost can be branched into 2 parts:
> 1) Learning the business model and logic implemented by OFBIZ
> 2) Learning OFBIZ's unique technical platform
> The first part cost is no doubt value-able and unavoidable, because it's
> closely related to the business and specific product.
> But the second part is the cost that doesn't gain any direct benefits to
> the business. So they like to find a way to cut down such cost. To find
> a new developer familiar with Grails is much easier than find a new
> developer familiar with OFBIZ platform, isn't it? The second part cost
> can be cut down to 0 by hire a qualified developer.
>
> * For NEW developers:
> Assume the worst case, the new developers doesn't familiar either of
> these technologies. Then he has 2 choices:
> 1) Spend 2 months to get familiar with the unique OFBIZ technical
> platform, which may get the OFBIZ job done, but nothing else.
> 2) Spend 2 months to learn a technology like Grails, which can not only
> solve the OFBIZ related requirements, but also suitable to solve a
> wide-range of web development problems.
> Which one do you think he/she would like to spend their time into?
>
> * For current Experts:
> They may need to learn a new technologies, but this is one-time cost.
> After this, they can be released from the long-last technical platform
> maintain task, concentrate on the core business issues.
> Although I don't know them yet, I bet the maintainers of the OFBIZ
> technical platform may have gathered a lot of improvement idea for the
> core platform already, inspired by other leading platforms. But they
> have limited time/effort to do so, or even just wondering: does it
> worthwhile to re-invent the wheels?
>
> -Miles
>
>
> On Wed, 2010-02-24 at 13:03 -0800, Adrian Crum wrote:
>> Miles Huang wrote:
>> > 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
>>
>> > 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.
>>
>> So we trade new users having to learn the OFBiz way for new users having
>> to learn the Grails way. What have we gained?
>>
>> -Adrian
>
>

Miles Huang

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

On Fri, 2010-02-26 at 10:06 +0100, Jacques Le Roux wrote:
> Miles,
>
> Well tried, from your argumentation I guess that
>
> 1) you certainly know Grail,
> 2) most of us don't,
I don't think most of you don't. Grails development is merely writing
Groovy code, with which most of you are familiar already. What make
Grails source code difference is many DSL extension specifically to
solve common WEB application requirements. Again you are also familiar
with DSL concept already, the mini-lang could be considered as a DSL
based on XML. Grails use Groovy DSL to gain similar high programming
efficiency.

> 3) you don't know much about OFBiz yet
>
> So you try to push Grail and we brake on it. As David wisely suggested in another email a POC is the way for you now...
>
> Thanks for you interest in OFBiz
>
> Jacques

Nice summary. I agree a POC will make things clear. A sample Grails
OFBIZ component would be a better discussion base.

Now I've heard the voice from the community and it's time to do more
research on the subject and learn more on OFBIZ itself. Hope I can work
out a sample component in Grails recently.

Thanks,
Miles.

Sascha Rodekamp-3

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

Hi Miles,
i really like to see a POC of an Grails OFBiz component.

I think this could be an interesting project.
So Miles keep on working :-)

2010/2/26 [hidden email] <[hidden email]>

> On Fri, 2010-02-26 at 10:06 +0100, Jacques Le Roux wrote:
> > Miles,
> >
> > Well tried, from your argumentation I guess that
> >
> > 1) you certainly know Grail,
> > 2) most of us don't,
> I don't think most of you don't. Grails development is merely writing
> Groovy code, with which most of you are familiar already. What make
> Grails source code difference is many DSL extension specifically to
> solve common WEB application requirements. Again you are also familiar
> with DSL concept already, the mini-lang could be considered as a DSL
> based on XML. Grails use Groovy DSL to gain similar high programming
> efficiency.
>
> > 3) you don't know much about OFBiz yet
> >
> > So you try to push Grail and we brake on it. As David wisely suggested in
> another email a POC is the way for you now...
> >
> > Thanks for you interest in OFBiz
> >
> > Jacques
>
> Nice summary. I agree a POC will make things clear. A sample Grails
> OFBIZ component would be a better discussion base.
>
> Now I've heard the voice from the community and it's time to do more
> research on the subject and learn more on OFBIZ itself. Hope I can work
> out a sample component in Grails recently.
>
> Thanks,
> Miles.
>
>
>

--
http://www.lynx.de

Chris Snow-3

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

In reply to this post by Miles Huang

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:

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

A possible answer:

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

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

Cheers,

Chris

Miles Huang wrote:

Chris Snow-3

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

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:
>
> "what does the ofbiz framework give you that the grails framework
> doesn't?"
>
> A possible answer:
>
> "Ofbiz gives you a ready made layout for backend management UI (i.e.
> screens, menus, forms)"

the ofbiz framework will give you an easy upgrade path to the full ofbiz
and all its business functionality.

>
> I can't think of anything other than this that the ofbiz framework
> provides that grails doesn't.
>
> Cheers,
>
> Chris
>
>
> 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.
>>
>

Jacopo Cappellato-4

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

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

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

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.

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

Jacopo Cappellato-4

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

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

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

I'm not looking for easy information. Based on my experience of ofbiz
and grails - I really don't know what else ofbiz brings to the table.

I was hoping that I'd missed something fairly obvious which is why I
threw the question out to the list.

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

123