Carsten Ziegeler skrev:
As you might have noticed I refactored our core in the last days a
little bit. The main change is the extracting of our Spring based
configuration stuff (the settings object, support for running modes,
reading of properties, reading configuration files directly from the
classpath etc.) and making it independent from the Cocoon web framework
part.
Great!
You can find this in the new core-spring module. It has only a
dependency on the core-configuration stuff (and spring of course).
I think we should do some marketing about this stuff as it is a really
useful piece of software which you can use in *every* spring based web
project. So if you are using e.g. spring with JSF you can use our spring
module for the configuration stuff as well! And you could even - hold
your breath - use this with Cocoon 2.1.x of course. And it brings you a
standarized way of handling running modes and properties with Spring.
Seem like a good idea. But in that case I think that we don't should use
"cocoon" as default name in some of the paths. The name of the module
should also be something more descriptive than "spring".
So I would like to combine the current three modules (configuration-api,
configuration-impl and spring) into one single module (or two if people
prefer separating the public stuff in this case as well) and then
release this as a 1.0 version as soon as possible.
I prefer having a separate module for the public API. If one use the
configuration stuff there will probably many components that depend on
the Settings object, and these components should not need to depend on
all of the implementation of the configuration mechanism.
Also I would like to be able to turn of the use of the DeplymentUtil. In
an OSGi context it is not needed and that might be the case in some
other ocntexts as well.
/Daniel
