> 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." > 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. 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. 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? > Craig sean
