Mike Kienenberger schrieb: > On 9/13/06, Ravindar Reddy <[EMAIL PROTECTED]> wrote: >> It would be good to split a monolithic jar into smaller jars with >> clear dependencies. This makes it easy for developers to choose the >> functionality based on the needs . >> >> I could think of the breakdown like: >> >> - a jar for dojo >> - a jar with shared utility code >> - a jar with all validators >> - a jar with all converters >> - a jar with components and renderers only >> - a jar with taglib codefor JSF components. (e.g: somebody >> instantiating JSF components dynamically do not need this) > > I think this is going too far. > > A jar for shared utility code, validators, converters, and > non-rendering components makes sense. Possibly even non-rendering > tags (like t:updateActionListener). > > As a facelets user, I could see the usefulness of a jar for taglib > code, but I honestly doubt it's worth the hassle. Functionality, it > doesn't add anything to have this division. > No I dont thing all this is needed as well, for most part we have to share non visual stuff, which means helper classes, converters, tools classes, and some shared resources.
In the long run going towards weblets for resources will make sense, for now we cannot. I can live with one commons jar for now but splitting it into more than one at the current situation is a burden for everyone. The users, the people using the jars, and the build maintainers. +1 for a shared component-commons upon which the component libs can build -1 for a finer granularisation for now from my side.
