> 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.
exactly > 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. Each pom.xml builds a single artifact (at least that seems to be the standard if not the rule.) So you have one directory (and a matching pom) for the api.jar, one for impl.jar and one parent directory to bind the resulting jars for api and impl into a single tarball. Also, if we have core/trunk/api and core/trunk/impl then when we tag/branch we only need to create one tag/branch for both. > 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. > That's a pretty good summary. Not perfect but the best solution we have so far. > Regards, > Simon Sean
