> Personally, I think the shared concept works fine. fine is a bit to much, right? But, yeah it works
> > 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. true. but since everybody uses maven... that shouldn't be a big deal, IMO but I can see that both approves have their "issues" > 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 +1 that's a side effect > 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. yup, I guess I now move to your direction, or... base-tomahawk :-) but... that doesn't fly at all. > 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. +1 -M > > Regards, > Simon > > -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
