So I've committed a fix on the NMR/karaf assembly so that it builds correctly and can be started. It does not fully work yet, mostly because the command bundles for NMR and JBI can't start correctly and karaf stops loading those (I've raised a JIRA and will fix that asap). So I think the first thing is to migrate the shell commands to use blueprint so that they are actually available in the shell.
On Wed, Aug 19, 2009 at 13:18, Guillaume Nodet <[email protected]> wrote: > > > 2009/8/19 Eoghan Glynn <[email protected]> > >> Thanks Guillaume, opening up the sandbox will make it very convenient to >> submit further changes. >> >> BTW have you had a chance to review the changes already made on this >> branch? >> > > I'm doing that right now. > I've already spotted some issues and I'll commit fixes tonight. > > >> >> The main issue remaining to be tackled is related to the blueprint usage >> in >> Karaf. Specifically whether the Spring-DM-style config used widely in the >> nmr modules can peacefully coexist with the blueprint usage in karaf, or >> whether the nmr configs will need to ported to blueprint in the >> short-term. >> >> Also a related question on the <command-bundle> style config for the nmr >> shell extensions, which will I guess have to switch over from the old >> >> http://servicemix.apache.org/schema/servicemix-gshell/servicemix-gshell.xsdschema >> to the new >> http://felix.apache.org/karaf/xmlns/gshell/v1.0.0 schema. Presumably >> usage >> of the latter implies a switch-over to blueprint for the commands config, >> but can that be done independently of the spring-dm config used by the >> non-command bundles? >> > > Right, commands could be switched over independantly. > For the other configs, it mainly depends if there are strong dependencies > on spring-dm. > Spring extensions dependencies might be ok (such as in the jbi cluster > engine which > depends on spring-jms), but we need to have an overview and discuss which > one we want > to migrate. > > >> >> Cheers, >> Eoghan >> >> 2009/8/19 Guillaume Nodet <[email protected]> >> >> > Btw, the sandbox has been opened to all Apache committers. >> > So Eoghan, feel free to make any change there. >> > >> > On Thu, Aug 6, 2009 at 18:10, Chris Custine <[email protected]> >> > wrote: >> > >> > > Just FYI for anyone monitoring this thread, Karaf integration is being >> > > tracked on this Jira issue: >> > > https://issues.apache.org/activemq/browse/SMX4-332 >> > > >> > > The sandbox code is at the following URLs: >> > > >> > > http://svn.apache.org/repos/asf/servicemix/sandbox/karaf/nmr >> > > http://svn.apache.org/repos/asf/servicemix/sandbox/karaf/features >> > > >> > > Chris >> > > >> > > -- >> > > Chris Custine >> > > FUSESource :: http://fusesource.com >> > > My Blog :: http://blog.organicelement.com >> > > Apache ServiceMix :: http://servicemix.apache.org >> > > Apache Directory Server :: http://directory.apache.org >> > > >> > > >> > > On Wed, Aug 5, 2009 at 11:43 AM, Jean-Baptiste Onofré < >> [email protected] >> > > >wrote: >> > > >> > > > Nevermind, I have just seen your jira tasks :) >> > > > >> > > > >> > > > Eoghan Glynn wrote: >> > > > >> > > >> Folks, >> > > >> >> > > >> I'd like to put what I've done so far onto an integration branch >> for >> > > >> review >> > > >> etc. >> > > >> >> > > >> Can some committer create such a branch for the NMR and features >> SVN >> > > >> repositories? Once this is done, I'll submit a patch for the Karaf >> > port. >> > > >> >> > > >> As I mentioned on another thread, there was a problematic >> dependency >> > > >> between >> > > >> the NMR/features integration tests and the old kernel >> > > >> AbstractIntegrationTest framework. After discussing this issue with >> > > >> Guillaume last week, I took the pragmatic approach of moving a >> > cut-down >> > > >> version of the testing support into the NMR repo. The problematic >> > tests >> > > >> are >> > > >> now passing. >> > > >> >> > > >> Cheers, >> > > >> Eoghan >> > > >> >> > > >> >> > > >> 2009/7/10 Eoghan Glynn <[email protected]> >> > > >> >> > > >> Seems like we broad agreement that this is a good thing, so I'll >> look >> > > >>> into putting together a patch. >> > > >>> >> > > >>> Obviously I'll need a committer to create the maintenance branches >> > > >>> before applying the patch to trunk. >> > > >>> >> > > >>> Cheers, >> > > >>> Eoghan >> > > >>> >> > > >>> >> > > >> >> > > > -- >> > > > Jean-Baptiste Onofré (Nanthrax) >> > > > BuildProcess/AutoDeploy Project Leader >> > > > http://buildprocess.sourceforge.net >> > > > [email protected] >> > > > PGP : 17D4F086 >> > > > >> > > >> > >> > >> > >> > -- >> > Cheers, >> > Guillaume Nodet >> > ------------------------ >> > Blog: http://gnodet.blogspot.com/ >> > ------------------------ >> > Open Source SOA >> > http://fusesource.com >> > >> > > > > -- > Cheers, > Guillaume Nodet > ------------------------ > Blog: http://gnodet.blogspot.com/ > ------------------------ > Open Source SOA > http://fusesource.com > > > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com
