Once more: Commons refactoring and releasing

[Manfred Geiler <ma...@gmail.com>]

Hi all,
Some more investigations and thinking led me to the following conclusion:
Key to all that confusion (me beeing the most concerned ;-) and to our
divergent points of view regarding commons release policy,
auto-repackaging (aka "inlining"), etc. is the mixture in the type of
classes we currently have in our commons module. Ok, that was not
really hot news for most of you, but thought until the end, this leads
to some interesting results.

I have created a Wiki page to share my thoughts with you:
http://wiki.apache.org/myfaces/MyFaces_Commons_Refactoring

I think in the long run we should end up with two modules:

1. myfaces-commons:
These are the real "commons" JSF classes that could be useful for or
every custom component or JSF application developer in the world.
Those classes will have a nice API that is stable and is downward
compatible (where possible).
This module will have it's own release cycle and version conflicts
should not be a greater problem than with other Apache commons libs.
And since Maven is cleverer than I thought when I depicted my
"unlucky" scenario there is also no problem to expect from that side.

2. myfaces-shared:
These are the classes, that are shared between the MyFaces impl and
our component libraries to prevent code redundancy.
To reduce the risk of version conflicts and to make the release cycle
of core and tomahawk really independent, the shared classes should not
be released as JAR, but should automatically be repackaged and
"inlined" into impl, tomahawk, tobago, etc.

Thoughts?

Manfred