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 > >
-- Chris Snow - CEng MBCS CITP MBA (Tech Mgmt) (Open) CISSP Tel: 01453 890660 Mob: 07944 880950 Www: www.snowconsulting.co.uk
