The goal of splitting is two-fold as I see it. 1) Move renderkit-independent resources into a separate jar. These validators/converters/non-renderers can be used with any JSF implementation, including those with incompatible renderkit issues like Tobago and Trinidad.
2) Make a set of common utilities and base classes with a public api that component developers can use. Code for resource providing, message bundle access, etc. I'm not sure we're ready to address #2 yet. I think we can address #1 right now, though. #1 would be functionally different from shared. #2 might be the same as shared (and probably should be). I think it's reasonable to only release the common code along with a regular tomahawk release. I don't think these need a separate release schedule. On 9/13/06, Wendy Smoak <[EMAIL PROTECTED]> wrote:
On 9/13/06, Mike Kienenberger <[EMAIL PROTECTED]> wrote: > 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. I'm okay with splitting Tomahawk into multiple jars, as long as they are versioned and released together. Calling one of these jars 'myfaces-components-commons' to indicate that it can be used without Tomahawk, is also fine. I'm not in favor of establishing a commons module that gets versioned separately. Having to branch Shared for every release of core and tomahawk is bad enough already. If it's possible, I'd almost rather make the common code part of Shared, since that already has to be branched for every release. Is the goal simply to share code between Tomahawk and Tobago, or do we also want make a commons jar available to users? -- Wendy
