On May 20, 2010, at 604PM, Peter Firmstone wrote: > Thanks Dennis, Maven's repository's just keep sounding better & better: > source and doc artefacts.
Thats the primary reason that I refactored Rio to not only support the resolution of service artifacts during deployment, but also refactored the Rio project to be a maven based project. I needed the help and guidance of people like Jeff Ramsdale and Jerome Bernard to get me going, but I'm glad I did it. I think the result is a much better developer experience and a better organized project. I know this may erupt in the visceral say no to maven campaign (and I used to be on the anti-maven side of that argument), but IMHO, key to (future?) adoption of River must be allowing developers to easily develop, test & deploy services that are based on River (and the other technologies that are bound to be included). Being able to use industry wide and accessible repositories and repository managers that have published artifacts is key to this. Certainly looking at Apache Ivy, and even if makes sense to look at OBR (who knows?) might make sense. I for one would support the conversion of River to maven. Having said that, we might want to start a different thread to discuss this issue :) > This is brilliant, a GUI Service Spec Maven browser would be sweet too. > Leveraging Maven's repository's could really get River out onto the net. If you havent tried this, check out http://repository.sonatype.org/index.html. Search for jini, or search for most anything you use. Chances are you'll see it listed. So we 'kind of' have a service artifact browser. In our case we would want to look for artifacts that have a classifier of 'api', or 'spec', or 'client (or whatever we decide). > > Chris, Dennis & Greg, your all spot on with the Service-spec.jar, I'd like to > add something to the jar Manifest of these Service Interfaces, to ensure > River loads it into the top level ClassLoader. Any suggestions? Why not just support the convention instead of adding configuration? > > We need some good doc's to really get the message across for these ideas. And examples. I'll try and fit this type of work into Rio's schedule. It would be great of all the 'container' providers would support the conventions being discussed here.
