On Apr 12, 2005 2:13 AM, Manfred Geiler <[EMAIL PROTECTED]> wrote: > > > My intention was to signal new users more clearly that this library is > > > independent of the myfaces implementation: myfaces-jsfcommons, a "JSF > > > Commons Library" under the "MyFaces" brand. That was the idea behind, > > > but perhaps I'm thinking too sophisticated :-) > > > I'm ok with myfaces-commons too, of course. > > > > > > > I can see the intent, but "commons" also implies (at least from my > > Jakarta Commons biased viewpoint :-) that the stuff here is generally > > reusable, completely separate from MyFaces, and that doesn't seem > > likely for what we've been describing here. > > That's exactly what is my intention: To have a place for all the stuff > that is reusable and independent from MyFaces. And that's what 99% of > the current classes in the shared src tree already are, though it > might not seem so at first glance. To give you an idea, I pick out > some classes: > - RendererUtils: a collection of convenient methods for Renderers > - MessageUtils: convenient helpers to add JSF Messages > - Html*TagBase classes: convenient base classes for writing derived Tag > classes > - Html*RendererBase: convenient base classes for writing renderers > that implement or extend the functionality of standard renderers >
That makes "commons" make more sense, but I still think a different name would be better. > Of course, there are small refactorings that have to be done. > And what is definitly bad now and offends the good tradition of > jakarta commons classes is the lack of documentation. To have a really > commonly usable myfaces-commons lib there is definitly some work to be > done. > So I still feel confident that myfaces-commons would be a name that > makes perfect sense even if it is an ambitious goal to aim at. > > > Consider: > > * support > > * shared > > * infrastructure > > Craig, I'm not sure I understand what you mean. Are these your name > proposals or hints for issues we should consider when we speak of a > separate "commons" subproject? Sorry for being slow-witted ;-) > Yes, those were meant to be name suggestions. Sorry for being too terse :-). Craig > > > > > By the way, it sounds like you agree that the > > > > API and Impl jars should be part of a single > > > > implementation project right? > > > > > > Yes, IMHO, we are allowed to focus the user first, that needs both API > > > and Impl at runtime. If we maintain a separate API jar and document > > > it, that is enough for the user, that needs only one of the JARs for > > > any special reason. > > > > Combining the JARs will *really* do a disservice to any potential user > > that is currently using the JSF RI (with pointers to separate > > jsf-api.jar and jsf-impl.jar properties), but wants to try MyFaces. > > Sorry for misleading. There must of course exist separate jars for api > and impl. No question. > > -Manfred >
