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

[Raj Saini]

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

                
            
        

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

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