> -----Original Message----- > From: Felix Meschberger [mailto:fmesc...@adobe.com] > Sent: Tuesday, April 17, 2012 12:49 PM > To: dev@felix.apache.org > Subject: Re: Enhanced Apache Felix / JRebel integration > > > Perhaps I can explain better with an example rather than in abstract > terms, so here's what I want to achieve in terms of development > experience: > > > > 1. Start Apache Felix with SCR capabilities and with the JRebel agent > > 2. Deploy a bundle with a JRebel configuration attached > > 3. Start listening for changes to the declared SCR descriptors of the > bundle > > That's part of JRebel support ?
Yes, and already available without any changes. > > > 4. When the SCR descriptors change on disk, call > PackageAdmin.refreshPackages() > > This is probably not adequate (or even required): What you would have > to do is just stop and start the bundles. refreshPackages would only be > required if you want the wires of the bundle refresh. Right, thanks. > > > > > I can safely do (4) the packages since JRebel already ensures that I > will get the most current version of the class without needing to > redeploy the bundle. I purposefully ignore how the changes will be made > for (3) since that's a different implementation topic. > > > > I am aware that this process does not make sense unless JRebel is > used, so that's why I'm trying to find out the best way of hooking into > the framework without the need to make invasive changes. > > The longer I think of it, the longer I think such a thing is really > futile ... > > Bundle deployment is generally really fast -- unless your bundle is > large and has a complex import/export list, which would make that > bundle a bad bundle by definition ;-) Agreed, bundle deployment is usually fast. However, the whole deployment process is not instant for me. My use case is based on Sling, not Felix standalone. I typically have to switch to the console and run something like 'mvn package sling:install' or hunt for the Maven build command in my IDE and click it. And all in all the process can take 10-20 seconds. All of that contrasted with saving a class and then refreshing a web page seems a lot. > I honestly fail to see the point of JRebel in an OSGi framework ... To rephrase what I've said above - it's not that fast, incremental developement is not supported by OSGi frameworks, it's that it's not fast enough for my goals. My tooling should be smart enough to 'refresh on save', without the need to ask it nicely to repackage and redeploy my bundle. There's also a blog post from one of the JRebel devs regarding how JRebel and OSGi fit together [1]. However, I can see why you're skeptical and when I'll have a proof-of-concept I hope to have some hard numbers to support to difference in speed. Robert [1] http://zeroturnaround.com/blog/jrebel-vs-osgi-use-the-right-tool-for-the-right-job/ > > Regards > Felix > > > > > Robert > > > >> > >> -> richard > >> > >>> > >>> Thanks, > >>> > >>> Robert > >>> > >>>> -> richard > >>>> > >>>>> I would like to validate that this is at all possible within > Apache > >>>> Felix and to ask which are the best places to start looking for > >> adding > >>>> the JRebel functionality. Any thoughts/pointers on how to best > start > >>>> developing this would be greatly appreciated. > >>>> > >>>>> If this is feasible, I intend to develop this as a separate > JRebel > >>>> plugin and contribute it to the Apache Felix project. > >>>>> Thanks, > >>>>> > >>>>> Robert > >>>>> > >>>>> [1]: http://zeroturnaround.com/jrebel/ > >>>>> [2]: http://zeroturnaround.com/jrebel/features/ > >>>>>
