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

[Miles Huang <hu...@gmail.com>]

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.
-- 
View this message in context: http://n4.nabble.com/Brain-storm-OFBIZ-on-Grails-is-this-a-right-way-for-the-future-tp1568009p1568009.html
Sent from the OFBiz - User mailing list archive at Nabble.com.

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

[Sascha Rodekamp <sa...@googlemail.com>]

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 huang.miles@gmail.com <hu...@gmail.com>

> 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

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

["huang.miles@gmail.com" <hu...@gmail.com>]

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.

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

[Jacques Le Roux <ja...@les7arts.com>]

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: <hu...@gmail.com>
> 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
> 
>

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

["huang.miles@gmail.com" <hu...@gmail.com>]

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

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

[Adrian Crum <ad...@hlmksw.com>]

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

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

[Erwan de FERRIERES <er...@nereide.fr>]

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

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

[David E Jones <de...@me.com>]

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.

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

[Miles Huang <hu...@gmail.com>]

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.

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

[Christopher Snow <sn...@snowconsulting.co.uk>]

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

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

[Miles Huang <hu...@gmail.com>]

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?
-- 
View this message in context: http://n4.nabble.com/Brain-storm-OFBIZ-on-Grails-is-this-a-right-way-for-the-future-tp1568009p1568878.html
Sent from the OFBiz - User mailing list archive at Nabble.com.

Re: OFBIZ OSGi - WAS: Brain-storm: OFBIZ on Grails

[Raj Saini <ra...@gmail.com>]

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" <ra...@gmail.com> 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 ...
>>     
>
>   

Re: OFBIZ OSGi - WAS: Brain-storm: OFBIZ on Grails

[chris snow <ch...@googlemail.com>]

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

On 9 Mar 2010 08:16, "Raj Saini" <ra...@gmail.com> 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 ...

Re: OFBIZ OSGi - WAS: Brain-storm: OFBIZ on Grails

[Raj Saini <ra...@gmail.com>]

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
>   

Re: OFBIZ OSGi - WAS: Brain-storm: OFBIZ on Grails

[Jacques Le Roux <ja...@les7arts.com>]

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" <ra...@gmail.com>
> 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
>>
> 

Re: OFBIZ OSGi - WAS: Brain-storm: OFBIZ on Grails

[Raj Saini <ra...@gmail.com>]

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
>   

OFBIZ OSGi - WAS: Brain-storm: OFBIZ on Grails

[chris snow <ch...@gmail.com>]

Hi Raj,

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

Many thanks,

Chris
-- 
View this message in context: http://n4.nabble.com/Brain-storm-OFBIZ-on-Grails-is-this-a-right-way-for-the-future-tp1568009p1582690.html
Sent from the OFBiz - User mailing list archive at Nabble.com.

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

[Raj Saini <ra...@gmail.com>]

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" <sn...@snowconsulting.co.uk>
>>>>>>>>           
>>>>>>>>> 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: 01453 890660
>>>> Mob: 07944 880950
>>>> Www: www.snowconsulting.co.uk
>>>>
>>>>
>>>>     
>>>
>>>
>>>   
>>
>
>

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

[Christopher Snow <sn...@snowconsulting.co.uk>]

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" <sn...@snowconsulting.co.uk>
>>>>>>>            
>>>>>>>> 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: 01453 890660
>>> Mob: 07944 880950
>>> Www: www.snowconsulting.co.uk
>>>
>>>
>>>     
>>
>>
>>   
>

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

[Raj Saini <ra...@gmail.com>]

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" <sn...@snowconsulting.co.uk>
>>>>>>             
>>>>>>> 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: 01453 890660
>> Mob: 07944 880950
>> Www: www.snowconsulting.co.uk
>>
>>
>>     
>
>
>   

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

[Chris Snow <sn...@snowconsulting.co.uk>]

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" <sn...@snowconsulting.co.uk>
>>>>>> 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: 01453 890660
> Mob: 07944 880950
> Www: www.snowconsulting.co.uk
>
>


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

Tel: 01453 890660
Mob: 07944 880950
Www: www.snowconsulting.co.uk

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

[Chris Snow <sn...@snowconsulting.co.uk>]

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" <sn...@snowconsulting.co.uk>
>>>>> 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: 01453 890660
Mob: 07944 880950
Www: www.snowconsulting.co.uk

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

[Raj Saini <ra...@gmail.com>]

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" <sn...@snowconsulting.co.uk>
>>>> 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.
>>>>>   
>>>>
>>>
>>>
>>
>
>

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

[Christopher Snow <sn...@snowconsulting.co.uk>]

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" <sn...@snowconsulting.co.uk>
>>> 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.
>>>>   
>>>
>>
>>
>

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

[Raj Saini <ra...@gmail.com>]

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" <sn...@snowconsulting.co.uk>
>> 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.
>>>   
>>
>
>

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

[BJ Freeman <bj...@free-man.net>]

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" <sn...@snowconsulting.co.uk>
>>> 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.
>>>>   
>>>
>>
>>
> 
> 

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

[Jacques Le Roux <ja...@les7arts.com>]

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" <sn...@snowconsulting.co.uk>
>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.
>>   
>

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

[Christopher Snow <sn...@snowconsulting.co.uk>]

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

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

[Ruth Hoffman <rh...@aesolves.com>]

Cool! Who knew.

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

Ruth


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

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

["huang.miles@gmail.com" <hu...@gmail.com>]

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

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

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

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

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

[Jacques Le Roux <ja...@les7arts.com>]

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

Jacques

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

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

[Ruth Hoffman <rh...@aesolves.com>]

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

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

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

["huang.miles@gmail.com" <hu...@gmail.com>]

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

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

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

[David E Jones <de...@me.com>]

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

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

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

-David


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

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

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

[Scott Gray <sc...@hotwaxmedia.com>]

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

Regards
Scott

On 26/02/2010, at 10:06 AM, huang.miles@gmail.com wrote:

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

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

["huang.miles@gmail.com" <hu...@gmail.com>]

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

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

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

[Scott Gray <sc...@hotwaxmedia.com>]

Hi Chris

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

Regards
Scott

HotWax Media
http://www.hotwaxmedia.com

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

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

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

[Jacques Le Roux <ja...@les7arts.com>]

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

Jacques

From: "Christopher Snow" <sn...@snowconsulting.co.uk>


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

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

[Christopher Snow <sn...@snowconsulting.co.uk>]

Hi Jacques,

Thanks for the comments.

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

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

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

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

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

Cheers,

Chris
|

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

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

[BJ Freeman <bj...@free-man.net>]

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

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

huang.miles@gmail.com sent the following on 2/26/2010 8:49 AM:
> Grails can also provides these ability, which is the fundamental spirit
> of "Rails" development environment, namely RoR, Grails.
> 
> On Fri, 2010-02-26 at 15:34 +0100, Jacques Le Roux wrote:
>> Also OFBiz is *great* when it comes to *not* compile, reboot, compile,
>> reboot, compile, reboot, compile, reboot, compile, reboot, 
>> compile, reboot, OK you see...
>>
>>
> 
> 

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

[Jacques Le Roux <ja...@les7arts.com>]

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

Jacques

From: "Ruth Hoffman" <rh...@aesolves.com>


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

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

["huang.miles@gmail.com" <hu...@gmail.com>]

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


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

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

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

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

[BJ Freeman <bj...@free-man.net>]

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

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

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

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

[Ruth Hoffman <rh...@aesolves.com>]

Hi Jacopo:

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

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

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

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

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

Ruth



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

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

[Christopher Snow <sn...@snowconsulting.co.uk>]

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

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

[Jacopo Cappellato <ja...@hotwaxmedia.com>]

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

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

[Christopher Snow <sn...@snowconsulting.co.uk>]

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

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

[Jacopo Cappellato <ja...@hotwaxmedia.com>]

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

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

[Christopher Snow <sn...@snowconsulting.co.uk>]

There's a set of instructions at:

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

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

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

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

[Christopher Snow <sn...@snowconsulting.co.uk>]

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

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

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

["huang.miles@gmail.com" <hu...@gmail.com>]

Please see inline...

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

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

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

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

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

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

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

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

[Christopher Snow <sn...@snowconsulting.co.uk>]

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

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

[Christopher Snow <sn...@snowconsulting.co.uk>]

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