Carsten Ziegeler skrev:
Daniel Fagerstrom wrote:
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".
Hmm, yes, I agree. Any suggestions? (I'm not good at finding names)
Something with configuration or setting maybe. That would say something
about the intended function.
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.
Agreed.
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.
True.
What do you think about merging the three packages (without thinking
about names yet):
a) Add the SettingsDefault, PropertyHelper and MutableSettings classes
to configuration-api. I think these three classes are things people
might want to use in their own code.
b) Add the DeploymentUtil to the spring module.
This leaves us with the modules, the configuration-api and the
implementation provided by the spring module.
+1
/Daniel
