The services repository would be a place to store non-core/third party Turbine services that could be utilized by anyone developing with the Turbine services framework. There are services that are stored in the main Turbine CVS that would be good candidates for the services repository: castor, xmlrpc, xslt, webmacro, freemarker, naming. These are services that Turbine can function without. Many Turbine developers have probably created services but have never offered them to the group because they are somewhat specialized: these services would be ideal in the repository because they would have a description and might be a great starting place for another developer. Or even better, a contributed service might be exactly what another developer needs.
There are also services in other OSS Turbine-based applications that would be good candidates for the services repository. Tambora has a rule service and processing service that could be useful for other Turbine-based B2B solutions, and the URL management and disk caching services in Jetspeed are also general purpose services that would be very useful to a wide audience of developers.
It would be nice to try and slim down the primary Turbine CVS. There are many services currently in that are not core services. These non-core services could easily be stored somewhere else and make the primary Turbine CVS easier to navigate and become familiar with.
It would be highly desirable to build up an extensive library of services. All of these services can't be kept in the primary Turbine CVS and so I imagine there are quite a few services out there that have not been contributed due to there specialized nature. Specialized services are ideal for the repository, if the services are kept in a central location and cataloged all parties involved will benefit.
Services would have to be functional from JAR files. For this to work the following changes would have to be made:
This would primarily affect the services framework, but the tools required to pull information from JARS and load the JARS could probably be used for loading/configuration sub-applications. We can probably borrow a lot of this code from Avalon as I think this is pretty much worked out in its service framework.