我从 JSF2.0 开始，我使用了一个教程作为参考，但我有以下问题：
本教程仅使用了 2 个库：jsf-api.jar，jsf-impl.jar（但也有 JSTL）来自 Mojarra 项目。
我也尝试下载它们，但似乎无法访问该站点。所以我使用了 Apache MyFaces，但是为了运行这个示例，我必须添加 8 个 jars ( commons-*, myfaces-*)。
如果我使用 MyFaces，为什么我需要更多的罐子？我应该更喜欢 Mojarra 打火机吗？另外下载页面确实是JSF Mojarra吗？
谢谢
如果我使用 MyFaces，为什么我需要更多的罐子？
因为这些commons-*依赖项没有捆绑在 MyFaces 中。另一方面，如果您使用来自 Apache.org 的其他库也使用这些commons-*依赖项，那么您最终会得到更小的总大小的库。
应该注意的是，从 Mojarra 2.1.6 开始，一个单一的 JAR 文件格式可用javax.faces.jar，因为 Mojarra 2.3.9 重命名为jakarta.faces.jar.
我应该更喜欢 Mojarra 吗？
这是一个非论证。您应该看看 JSF 实现的健壮性和维护性如何。
Mojarra 的祖父 Sun JSF RI 1.0 和 RI 1.1 的早期版本都被讨厌的错误弄得一团糟。那时（大约 2004-2006 年），MyFaces 绝对是更稳定的选择。
自 2006 年初左右的 1.1_02 和 1.2_02 以来，新的 Sun/Oracle JSF 开发团队做得很好。不仅可以修复错误，还可以增强性能。在 Mojarra 1.2 生命周期的一半左右（大约 2007-2009 年），Mojarra 是比 MyFaces 更好的选择。
自 JSF 2.0 以来，带有新的部分状态保存管理，MyFaces 在性能方面是更好的选择，因为计算状态增量的不同且更有效的方法，特别是在使用大型组件树时。Mojarra 仅从 2.1.22 版本开始赶上。在 2.0/2.1 时间线中，Mojarra 仅<ui:repeat>在复杂/嵌套组合（损坏状态保存、仅处理最后一个迭代形式、失败<f:ajax>等）和闪存范围实现（初始实现完全不是防弹）方面存在严重问题。MyFaces 也有自己的一组错误，但它们是可控的。
现在，对于 JSF 2.2，我们并不能真正预先说出哪个更好。错误通常只在以后才暴露出来，而健壮性只能在事后评估。只需选择您“认为”最好的任何实现。浏览他们的问题报告（MyFaces和Mojarra）以了解以前修复的问题和当前未解决的问题。如果您遇到特定错误，请尝试使用这两种实现来排除一个和另一个。如有必要，请报告以保持两个实施的整体质量较高。
另外下载页面确实是JSF Mojarra吗？
他们的主页已经移动了好几次。目前（2019 年 11 月）它位于https://eclipse-ee4j.github.io/mojarra。org.glassfish:jakarta.faces你也可以在 Maven Central 中找到这些库。eclipse-ee4j/mojarra您可以在 GitHub的项目中找到源代码。
答案来自我的博客：
http://lu4242.blogspot.com/2011/06/10-reason-why-choose-myfaces-core-as.html http://lu4242.blogspot.com/2012/05/understandingjsf-2-and-wicket .html
2013 年 7 月更新：请参阅 JSFCentral 上的系列文章和 2013 年更新：
http://www.jsfcentral.com/articles/understanding_jsf_performance_3.html
乍一看，两个 JSF 实现（MyFaces 和 Mojarra）都做同样的事情，因为它们基于相同的标准。您可以从一种实现更改为另一种实现的事实是 JSF 标准规范的质量事实。
但归根结底，MyFaces Core 2.x 比 Mojarra 更好的原因有很多。注意我是 MyFaces 项目的提交者，所以我在这里只给你我的观点：
2012 年 5 月更新： 2.1.0：47、2.1.1：6、2.1.2：84、2.1.3：9、2.1.4：74、2.1.5：7、2.1.6：35、2.1.7： 52
社区胜于代码：MyFaces 社区拥有许多对 JSF 有杰出知识的人。订阅用户和开发邮件列表是了解正在发生的事情、接收反馈和了解其他对 JSF 感兴趣的人的最佳方式。查看MyFaces 邮件列表
众所周知，Apache 从 Sun/Oracle 汲取了一切并使其变得更好。在这种情况下，MyFaces Core 对部分状态保存、复合组件等进行了一些很酷的优化！
MyFaces Core 是 OSGi 友好的。当您需要对类加载进行更多控制时，它提供了一些 SPI 接口来处理特殊设置。
MyFaces Core 与 facelets 1.1.x! 的兼容性更好。只需将 org.apache.myfaces.REFRESH_TRANSIENT_BUILD_ON_PSS Web 配置参数设置为 true，就会激活特殊模式。没有 c:if 标签或 c:forEach 或 ui:include 损坏了！。2012 年 5 月更新在 MyFaces Core 内部完成了一种改进的算法，即使在使用 facelets 动态更新组件树时，它也可以减少部分状态大小。不再需要此参数。
MyFaces 有其他项目（Trinidad, Tobago, Tomahawk, ExtVal, CODI, Orchestra, PortletBridge RI, ....）帮助保持代码调整，因为所有这些项目都针对 MyFaces Core 进行测试，如果有错误，那就是处理得更快。
您可以使用 svn 签出并轻松构建任何 MyFaces 项目，因为它们都基于 maven，并且大多数 IDE 都提供 maven 支持。
Mojarra 目前（2011 年 6 月）有一些与状态保存相关的严重错误，而 MyFaces 没有，因为它的实现完全不同。事实上，MyFaces 部分状态保存算法提供了比 Mojarra 更好的与 JSF 1.2 状态保存的兼容性。但请注意，Mojarra 的人正在努力解决这个问题，但要解决这个问题需要几个月甚至几年的时间。
创新发生在 MyFaces 上。
2012 年 5 月更新
请参阅本文选择 MyFaces Core 作为 Web 应用程序的 JSF 实现的 10 个理由
对于想要查看 MyFaces、Mojarra 和 Wicket 之间的性能比较的人，请查看了解 JSF 2 和 Wicket：性能比较
2013 年 7 月更新
比较扩展到包括其他框架，如 Spring MVC、Tapestry、Grails 2 和 Wicket。请参阅 JSFCentral 上的文章：2013 年 7 月在 JSFCentral 更新
我会说这真的没关系。
我最近使用 Myfaces 和 Primefaces 启动了一个 JSF 2.0 项目。上周，为了调查一个错误，我尝试在 Mojarra 上运行它。所要做的就是交换 JAR 并删除 web.xml 中特定于 Myfaces 的条目 - 一切正常，没有任何问题。诚然，这是一个没有使用所有 JSF 功能的原型，但是通过标准遵从性的兼容性演示给我留下了深刻的印象。
如果我使用 MyFaces，为什么我需要更多的罐子？
我通常坚持使用 Mojarra 实现，除非有其他理由。我使用 Netbeans，所以最容易使用“默认”项目设置，它使用在 GlassFish 下运行的 Mojarra。
上次我使用的是 MyFaces，这是因为我正在考虑使用 Tomahawk，并且使用同一来源的 JSF 实现似乎是合理的。但是我已经改用 Primefaces 并且在 Mojarra 下运行良好。
现在，随着 JSF-2.0 组件库的上线，似乎正在进行大量的开发工作。因此，您应该学习并能够在 JSF 实现之间切换，以防出现问题。
MyFaces 中包含更多 jar 的原因是它具有比参考实现更多的功能。
您使用的是哪个 IDE？如果您使用的是 Eclipse，那么它将在创建 jsf 2.0 项目时下载 jars。检查这个http://www.icesoft.org/training/icefaces-self-serve-training.jsf
mojarra 和 MyFaces 之间没有太大区别。您可以检查哪个版本更稳定。正如 Balusc 所说，MyFaces 是最稳定的版本（2005-2006 年）。此外，很多人在 2.0 之后开始使用 Mojarra，因为它与 myfaces 相比变得稳定了
I was having serious headaches with mojarra (2.2.8), weird behaviours such as ajax methods only running after the second user interaction due to previous form updates. All gone with MyFaces.