> > Do we really want component like stuff like converters and validators there? > > Didn't we discuss this already? > > Yes we had discuss this, but it seems we did not reach agreement. > > I think we need a own project for converters/validators/other stuff > for application-development > which should not include renderkid/jsf-impl dependend stuff.
+1 that was my real motivation for creating a "commons". I really don't care on a "coolBackingBean". Utils might be the better wording for that. > > An i think this one was meant by Matthias and Bernd. I think so :-) > > If we need jar supporting component-developer we should stop the > repackaging of shared, create a shared.jar and add the dependency > instead to impl and tomahwak. that would easy the debugging as well. Perhaps we need "stricter" rules for API stability for that. One major pain was that upgrade from tom1.1.2 to 1.1.3 wasn't possible, because the whole shared messed up the migration. > > (Just my thoughts) > Regards, > Volker > > > > I thought we agreed on not starting yet another jsf component lib. > > What is wrong with having convenient converters and validators in > > tomahawk? Where they are right now! > > Is it because tomahawk has some flaws and maybe have sideeffects on > > other component libs? If yes, we have to FIX tomahawk and not turn > > around and start a new (better?) project. > > > > My original idea of a jsfcommons project is/was: > > - convenient utils, helpers and base classes for component developers > > - convenient backing(!) bean utils and helpers for jsf application > > developers (ie "users") > > > > What jsfcommons should NOT be: > > - a convenient haven for simple components or component like stuff, > > that is put there for "strategic" reasons > > > > A need for a "jsfcommons-faces-config.xml" is a definite sign, that we > > would start off in the wrong direction. We would start yet another jsf > > component lib. That is the main reason I warned of having a > > faces-config.xml in jsfcommons in former discussed. It was not only > > for technical reasons. > > > > --Manfred > > > > > > > > On 11/29/07, Mario Ivankovits <[EMAIL PROTECTED]> wrote: > > > Hi! > > > > I don't think a separation between api and impl jars is useful. > > > > > > > I second that. For the same reasons. It makes things unnecessary > > > complicated .... > > > To ensure api stability community review should be enough - and then > > > there is a maven plugin for that, no? > > > > > > BTW: I thought we agreed on a structure like > > > myfaces-jsfcommons-converters > > > myfaces-jsfcommons-validators > > > ... > > > > > > Also overly complex, but something I can learn to understand .... > > > > > > Lets reiterate: I prefer to start with a simple jsfcommons project where > > > we have no faces-config.xml (at least not in a place where JSF loads it > > > automatically). > > > Providing a jsfcommons-faces-config.xml which the user has to add to the > > > configuration will avoid any side-effect when dropping in our jsfcommons > > > jar. It also allows to selectively active things as the users can change > > > their own configuration as required. > > > > > > Regarding the sandbox: I'd like to suggest to use the tomahawk sandbox > > > for myfaces land at all. Lets promote the tomahawk-sandbox one level > > > higher - thats it. > > > > > > Ciao, > > > Mario > > > > > > -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
