On Apr 11, 2005 11:24 AM, Sean Schofield <[EMAIL PROTECTED]> wrote: > > 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. Consider: > > * support > > * shared > > * infrastructure > > Good point. > > > gadgets? goodies? > > Goodies is interesting. Right now that is how I refer to this > package. I added some documentation to the website that mentions this > package has both true components and other "goodies." >
:-) > I agree with Manfred that the term components might be too narrow. > IMO if we pick a codename for the subproject (like was done for Shale) > then we can avoid this problem. We can just call it "foo" and then in > the subproject documentation describe this as a set of components and > other "goodies." Although even a code name should be general in nature, since it's likely that some of the foo things that are initially part of this would "graduate" to be separate releases later. > > > 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. > > I don't think this is what Manfred meant (its definitely not what I > meant.) I just meant that we should keep the *source* for the two > jars in the same project, even though there will ultimately be two jar > files. I don't think anyone wants to merge the two jars. Glad to here that wasn't the idea. I agree with the "same project" concept although, from a technical point of view, *all* the source code for MyFaces is in the same "project" -- it's really about directory structure within the repository. For that, it's still likely to be convenient to have the api and impl classes in two separate directories that are parallel to each other. > > As a side note, I do question why it makes sense to have the two jar > files in the first place since there is really not much to > implementing the API. Actually, JavaServer Faces is an exception to this normal rule -- there is quite a lot of functionality built in to the javax.faces classes; compared for example to how few concrete classes you find in javax.servlet or something like that. This was done to improve portability -- developers can use "javax.faces.component.UIOutput" on anyone's implementation without having to change class names -- but this required rather more concrete classes than one would usually require. > Who would want to use Sun's API but MyFaces > impl? Of course this is the spec/convention so we will continue to > follow that but it always seemed a bit strange to me. Couldn't there > just be a single Sun API jar that we all use? This follows an architectural principle that has been done with all the recent Java APIs, especially the ones that are going in to J2EE at some point. Indeed, that's going to become an issue for MyFaces with JSF 1.2, which becomes part of the J2EE platform. It will be necessary to verify that either: * Can load the MyFaces API and IMPL classes from WEB-INF/lib * Can load just the MyFaces IMPL classes and use the built-in API classes (or both) will work in a 1.2 time frame. Not an issue now, but will be later. > > sean > Craig
