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" <[email protected]> >>> 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. >>>> >>> >> >> > >
