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:

The Services framework would have to be altered to load services
packaged in the form of JAR files.

Dependent services would have to be listed in the manifest so that the
the initialization of a service could be deferred until all
prerequisites of the service have been initialized.

The service package in a JAR should state all of its configuration
options as it may be necessary to have this configuration information
extracted from the JAR and added to TR.props or whatever future
configuration mechanisms we devise. It might be nice to have an
option in Turbine where there is no TR.props to begin with but
starting Turbine with a certain option would produce a configuration
that reflected the use of a set of services. Or Turbine would start,
but would require some configuration from via a little web application
before Turbine would accept connections from the outside world.

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.