Manfred Geiler schrieb: > Mario, you are not alone in hating the shared concept. ;-) > > This is exactly where the "myfaces-commons-xxx" library comes into > play, I often mentioned before. > What we need is a module, that > 1) has a super stable API > 2) is used (ie. shared) by the myfaces core(!) as well as other myfaces > projects >
Personally, I think the shared concept works fine. One problem with a "commons" jar used by core is that Sun Mojarra will need two jars (jsf-api, jsf-impl) and myfaces will need three (jsf-api, jsf-impl, commons-whatever.jar). This is rather ugly. I'm also sceptical that it will be possible to create a "super stable API". Just look at what is in shared at the moment! And in addition to the API, the *implementation* will also need to be super-stable. For example, if a Tomahawk issue (whether bug or new feature) needs changes in the "commons" module to resolve, then deploying that commons change will immediately impact myfaces-core too. Suddenly people will be running a version of myfaces-core together with a commons version that it was never tested against. I don't like that idea at all. It was precisely this issue that the shared repackaging idea was invented for. We can improve the build process by having a maven plugin that imports-then-renames, rather than messing with the shared project to generate the per-user variant. That's really quite simple, and could be a nice general-purpose plugin. The maven-shade-plugin does something similar, but at the binary level. Earlier releases of myfaces did not include the "shared" source in the -sources jar which was a major nuisance. But that is now fixed. So for most users, there is no need to ever deal with the original shared project. Regards, Simon
