> The stuff we have (or plan to have) and we need places for are: > 1. "renderkit independent stuff" - converters, validators, ... (BTW, > are they really renderkit independent? What about client-side > validation?!)
let me write a wiki page for that + discussion in a separate thread. -M > 2. convenient utils, helpers and base classes for component developers > 3. convenient backing(!) bean utils and helpers for jsf application > developers (ie "users") > 4. some things in "myfaces-shared" that should not be there (BTW, I > have concrete plans on refactoring shared, but first I need a place > where I can move some stuff to) > 5. ??? > > Let's try to agree on these different categories. After that we try to > find the proper place and name(!) for each item? Okay? > > See inline as well --> > > -- Manfred > > > On 11/29/07, Matthias Wessendorf <[EMAIL PROTECTED]> wrote: > > > > 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. > > Aren't commons modules as we know it all "utilities" in some sense? ;-) > > > > > > > > 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. > > Yes, that's what I want to try. But "shared" is no proper name for > stuff that could be used by "independent" component developers. The > name "shared" means: this is internal code *shared* by some MyFaces > subprojects. Therefore we need a better place: "jsfcommons-???" > > > > that would easy the debugging as well. > > why? If you have both sources for api and impl jar in your IDE there > is no difference. > > > > > 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
