>> >> The standard I proposed is what is currently implemented by River-Container. >> Rio’s convention is very much different, and relies on reading jar files >> from a Maven repository rather than from the local file system. It >> represents a radical departure from the Service-Starter conventions, >> although it is compatible with the services. > > This is false. Rio provides the capability to declare a service be loaded > either by artifact resolution or by using declared jars. I have never moved > away from the latter approach for the simple reason that there are > deployments that require legacy support.
My mistake. Thank you for the correction. > > Using an artifact to annotate a codebase, or to resolve a service's classpath > provides significant advancement in the build-deploy lifecycle for > developers, and also provides performance benefits when accessing a service's > codebase (as well as addressing perm-gen oome for containers). > Makes a lot of sense. It’s something I’m intending to look into. >> > > I'm thinking that way too. For now, I am withdrawing my offer of donating Rio > to River. My intention was that it would greatly benefit River, by > dramatically improving the out of box experience. I'll be happy if River > would just mention it as a notable project that may be beneficial to > developers getting to know River. > > I'll also comment on your service archive standard, and if reasonable (and > given time) I'll provide support for it in Rio. > I recognize your earlier concerns about the River project appearing to favour one container over another. As such I’ll continue development of the River-Container outside the Apache River project. I guess it’ll need a new name. I’m not sure if we should leave River-435 open to discuss the service packaging. Perhaps others can comment... > Regards > > Dennis Cheers, Greg Trasuk
