Reinhard Poetz wrote:
Vadim Gritsenko wrote:
Leszek Gawron wrote:
Grzegorz Kossakowski wrote:
Leszek Gawron pisze:
SimpleFormInstanceExtractionTransformer.java and
SimpleFormTransformer.java are probably better placed in
cocoon-pipeline-components than cocoon-core. Can I move them ?
What's their use?
At CocoonGT we had some sort of agreement to create optional modules
Please, no more modules. It is bad already as it is - adding *more*
modules only makes it worse. What's wrong with simply deprecating
them, with placing appropriate javadoc?
+1 to move to -components, these are certainly not -core.
But this doesn't solve the problem that many components are loaded into
the spring app context by default. Having them into a seperate module
makes it easy to exclude them. But of course than you can run into the
situation that you only need one of them and get them all loaded again :-(
However, what we could do is introducing a rule that every *.opt.xml
file in META-INF/cocoon/spring and META-INF/cocoon/avalon isn't loaded
automatically but needs to be included explicitly.
gosh this is hacky :). How are the users are going to differentiate
which jars contain automatically loaded contexts and which not?
Plase mind we are heading for source less releases.
For users the message should be simple: put the jar on the classpath -
cocoon will pick up the components. Do not put it there if you want your
cocoon lighter.
Would that be that problematic to have cocoon-pipeline-core-components
and cocoon-pipeline-optional-components? Both could be imported into
sample app but only core for webapp archetype?
Or a variation of this idea: In 2.2 *.opt.xml files are loaded and there
is some configuration parameter to turn off this behaviour and in 2.3
it's the opposite.
Could this feature be easily added to the Spring configurator?
WDOT?
--
Leszek Gawron http://www.mobilebox.pl/krs.html
CTO at MobileBox Ltd.
