A taglib and a faces-config in the META-INF are loaded/registered automatically. And as I already mentioned, it should be possible to use the commons utils from the core impl. Automatically loading extensions(!) is not what we want when using the myfaces core implementation. There is some stuff in shared that makes sense to be moved to commons utils. So this is not only theoretical.
And don't forget about all those (renderkit-independent!) converters and validators. People might argue for putting them into a jsfcommons components artifact. What about the Joda converter that Matthias suggested? What is the reason it should go into Trinidad? It is not renderkit-specific or somehow related to Trinidad. So, a perfect candidate for jsfcommons-components, right? (There would even be place for a separate jsfcommons-converters artifacts, IMHO) BTW, I do not understand why some of you are so scared by multiple jsfcommons artifacts. The Apache Commons Proper consists of 35 different "Components" and nobody cares. Quite the contrary, everybody is glad there is not only one bloated commons.jar when he/she needs just commons-logging or some of the DbUtils, right? --Manfred On 10/31/07, Volker Weber <[EMAIL PROTECTED]> wrote: > > What is the problem having a taglib in the jar? > > 2007/10/31, Manfred Geiler <[EMAIL PROTECTED]>: > > > > > > On 10/31/07, Mario Ivankovits <[EMAIL PROTECTED]> wrote: > > > Hi! > > > > > > > > > which is itself an "umbrella" project for two artifacts** > called > > > > > "MyFaces JSF Commons Utils" and "MyFaces JSF Commons > Components" > > > > > > > > I suggest that I prepare an initial setup, and check it in, so that > > > > there is some concrete stuff we can talk about. > > > > Ok? > > > I still don't get why we should increase the number of modules here. > > > Two artifacts means two jars, no? > > Yes, sure. > > > > > > > And then, what is a Component? I think we agreed that we just want to > > > add render-less components, no? Else it has to go into tomahawk. The > > > Commons should not be just a "component-library without (the dreaded) > > > shared". > > > > > > Is a UrlNavigationHandler a Component then or a util? It has no > > > component yet, but what if it has one in the future? > > > I know, we then can simply just add this component to the Components, > > > but why should we split the stuff? > > > > > > In this case I'd have a > > org.apache.myfaces.commons.urlNavigationHandler > > > package where everything lives in. > > > > > > org.apache.myfaces.commons.urlNavigationHandler (the api) > > > org.apache.myfaces.commons.urlNavigationHandler.impl > > > org.apache.myfaces.commons.urlNavigationHandler.component > > > etc > > > > > > > > > > > > Also renderkit independent "components" need a taglib in the META-INF > dir. > > This is the main difference between a "component" and a goodie class a > user > > can decide to use or not. > > > > --Manfred > > > > > -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
