> I prefer Matthias' proposal for Apache Faces. I think it'd be great to > have all JSF-related technologies in one project.
Yes. This is a good idea if we can get buy in from Shale folks, etc. > As for the Faces components, as long as they're MyFaces components, > people will be confused about using them standalone. We can add > documentation, but people will still be confused. The only way to > eliminate the confusion is to put them in a separate project. I disagree. Having a big Apache Faces project with lots of little subprojects is also likely to confuse people. I imagine there are people confused by the jakarta project and all of its subprojects. "Do I have to use all of the jakarta projects if I just want digester?" > I think the components will thrive independent of MyFaces. The JSF > community needs a good open-source component set independent of a > particular JSF implementation and I feel like we're hiding one inside > MyFaces at the moment. I agree the components could thrive independent of the MyFaces implementation. Right now I think the components serve as a "hook" to get people interested in the implementation. As I think about it, its starting to make more and more sense that components be their own project (at least within myfaces if not a larger apache faces project.) There are still some issues to be worked out and a move to subversion would definitely be a good step at some point. > Finally, I don't think Shale should be part of MyFaces. If Shale is > absorbed with MyFaces, we'll have exactly the same problem that we have > with the components: people will wonder if they can use Shale with > other JSF implementations. A certain percentage will eschew Shale (and > the components) because they will assume they're MyFaces specific and > never take the time to investigate, or read the documentation. I agree that Shale should not be part of MyFaces. I think it would be a companion subproject in the larger Apache Faces project along with MyFaces and the components. If the Shale folks don't want to do this then there would be no point in a larger Apache Faces project until there were some other related technology besides what is already available in MyFaces. In other words, lets not move to a larger Apache Faces project that just has components and MyFaces. That is just a labeling change. MyFaces would not be combining forces with any other JSF realted project. > IMO, MyFaces should strictly adhere to providing a robust JSF > implementation. Some extensions that are tied to the framework, such as > Tiles support, are fine, but adding things to MyFaces that have nothing > to do with MyFaces, per se, invites confusion and limits the adoption > of those technologies. Here is a possible roadmap: 1.) MyFaces releases 1.0.9 as currently structured 2.) MyFaces splits into two or three subprojects: api + impl (or api and impl as two separate subprojects) and components (also source is migrated to SVN) 3.) Apache Faces project with the MyFaces and components subprojects 4.) Shale as part of Apache Faces project Steps 1. and 2. seem to have a lot of support and would seem to be prudent intermediate steps before we attempt anything more ambitious. Step 3 doesn't make much sense without Step 4. And Step 4 depends on the Shale team and also on whether or not Shale becomes Struts 2.0. > david sean
