On Mon, 2006-01-16 at 11:50 -0800, John Fallows wrote: > Sorry, I meant what is the purpose of having a core module at all? > (not, why is it structured in this way) > > In other words, who is going to use this module. Why does it need to > exist?
> I'll try to clarify. I think what Sean's "core" is meant to be is simply an "assembly" project, where myfaces-commons.jar, myfaces-api.jar and myfaces-impl.jar get bundled into a myfaces.tar.gz or myfaces.zip file. I don't quite know why this can't be done in the myfaces-impl.jar project but I guess there's some technical maven reason. This is *not* like the old "share" module which contained java classes that was then inserted into multiple jars; as you say that causes nasty issues when the jars are deployed via different classloaders. The common code now goes into "myfaces-commons.jar", which must be deployed *once only* in the classpath. There is a slight gotcha with the "myfaces-commons.jar" approach. Imaging someone preparing a webapp using tomahawk that may be deployed on a container that bundles Sun RI, or may be deployed on a container that bundles myfaces-commons.jar and myfaces-api.jar. If they don't bundle myfaces-commons.jar, then the app won't work on Sun RI. If they do, then on the myfaces-based container they have duplicated myfaces-commons.jar, and therefore (if child-first classloading is selected) will get the ClassCastException problem. However it's not too serious a problem and I can't see any better solution other than some of the early complicated proposals that included automated renaming of all the "commons" classes so they could be bundled with both impl and tomahawk without conflict. Regards, Simon
