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
