Hmpf Last time the discussion ended with some open issues. I think it's all about naming. That's the main reason for different views and opinions I think.
To gain a common view on things I try to subsume without giving names first. 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?!) 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 > > > > > > > > >
