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
