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

[Raj Saini]

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" <sno...@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.