notice: javaserverfaces/mojarra is read-only now
|
Kyle Stiemann
Hi Zhijun, Since the public repo has been archived, how does Oracle plan to maintain the 2.3.x, 2.2.x, and 2.1.x versions of Mojarra? How can the community contribute fixes and bug reports for those versions? How often will those versions of Mojarra be released? - Kyle On Tue, Apr 24, 2018 at 3:48 AM, <ren.zhijun@...> wrote:
|
|
|
|
ren.zhijun@...
Hi, Please be aware that the repository javaserverfaces/mojarra has been archived as this project is now part of the EE4J initiative. All activities are now happening in the corresponding Eclipse repository ee4j-mojarra. The issue tracker is now located at issues; the EE4J community mailing list is located here [https://accounts.eclipse.org/mailing-list/ee4j-community]. Thanks, Zhijun
|
|
|
|
Ed Bratt
Kyle,
The intent of changing the status of these repositories is to support the community migration over to Eclipse Foundation, Jakarta EE. It is our goal that all work, evolution and focus supports Jakarta EE. We hope to avoid confusion and/or dilute the efforts to grow the Jakarta EE community effort. We intend to only provide crucial corrections to any legacy material that remains under the legacy Java EE GitHub organization. The general guidance for contributions to Eclipse is to migrate the latest version only, without history. If the community requires additional materials be contributed, we may be able to consider that. At what frequency would you estimate these branches are being updated? -- Ed |
|
|
|
Kyle Stiemann
Hi Ed, We contribute fixes for legacy versions of Mojarra (often for 2.2.x, rarely for 2.1.x, and only for security vulnerabilities in 1.2.x). We want to be able to continue contributing fixes and repairs for our mutual customers and community. Mojarra 2.2.x (JavaEE 7) is still widely used and probably needs to be updated quarterly. 2.1.x only needs to be updated when serious bugs or security vulnerabilities are fixed, so once or twice a year. Security issues are the only reason that 1.2.x needs to be updated, so in the rare instance that a security bug is found in 1.2.x, it would need to be updated. Thanks, - Kyle On Tue, Apr 24, 2018 at 11:40 AM, Ed Bratt <ed.bratt@...> wrote: Kyle, |
|
|
|
ren.zhijun@...
Hi Kyle, Thanks for your question, during the donation process, if you
want to file issue or commit code, you can notify me and I can
un-archive the project temporarily for you. The release cut will
be done according to the requirements from upper products. We are discussing how to handle legacy releases support and maintenance after the donation is done. Thanks, Zhijun On 24/04/2018 9:13 PM, Kyle Stiemann
wrote:
|
|
|
|
Kyle Stiemann
Thanks Zhijun, I guess I misunderstood your initial email. Are you saying the the project is only archived temporarily (and oracle has yet to decide how to handle legacy releases)? I thought that the project was being permanently archived and that the Liferay Faces team would have no way to contribute fixes for legacy releases. - Kyle On Tue, Apr 24, 2018 at 10:13 PM, <ren.zhijun@...> wrote:
|
|
|
|
Bill Shannon <bill.shannon@...>
Hi Kyle.
toggle quoted message
Show quoted text
We have a plan for how to support older releases but we're still discussing the plan to make sure it's workable. In general, we expect support to move to the Eclipse community and the Eclipse Mojarra project. We're only contributing the current release to Eclipse so support for older releases has to be handled differently. At this point we only expect to be dealing with critical security problems in older releases, which hopefully will be relatively rare. If such a problem occurs, we can unarchive the old github project temporarily while we fix the critical security bug. For other issues, we hope the community will quickly move to the Eclipse version. Is Liferay distributing versions of Mojarra with Liferay products? Kyle Stiemann wrote on 04/25/18 06:02
AM:
|
|
|
|
Kyle Stiemann
Hi Bill, The Liferay Faces team is currently working on JSR 378 which is a Portlet Bridge for Portlet 3.0 + JSF 2.2. The JSR for Portlet 3.0 + JSF 2.3 hasn't yet been filed. Our customers are using Java EE 7 app servers which are not compatible with Mojarra 2.3. And since many app servers (including Oracle's own WebLogic Server) only support Java EE 7 right now, there is no way to upgrade to Mojarra 2.3. We need to be able to provide bug fixes for Mojarra 2.2 for the sake of our customers who are using these standards based technologies. Mojarra 1.2 and 2.1 only need security fixes, but Mojarra 2.2 is still widely used and depended on by many projects with no option to upgrade to Mojarra 2.3, so we need to be able to fix bugs and get regular releases for it. - Kyle On Wed, Apr 25, 2018 at 4:51 PM, Bill Shannon <bill.shannon@...> wrote:
|
|
|
|
Bill Shannon <bill.shannon@...>
I would expect that the Java EE server vendors would be providing
any required updates to the version of JSF included with their
server. That's what Oracle will do for WebLogic. Exactly how we
do that for older versions is still under discussion. Kyle Stiemann wrote on 04/25/2018 04:05
PM:
|
|
|
|
Neil Griffin
Hi Bill,
toggle quoted message
Show quoted text
I'm sure there are many JSF webapps out there running on Tomcat that simply bundle Mojarra in WEB-INF/lib. Portlet applications in Pluto do not rely on the version of JSF included with the server, since the only released distribution of Pluto is for Tomcat. Similarly, portlet applications in Liferay do not rely on the version of JSF included with the server. We would be grateful if Oracle would consider releasing Mojarra 2.2 on an as-needed basis for the next year or so. We will focus on supporting JSF 2.3 in a portlet environment as soon as we get JSR 378 out the door. Best Regards, Neil On 4/26/18 4:34 PM, Bill Shannon wrote:
I would expect that the Java EE server vendors would be providing any required updates to the version of JSF included with their server. That's what Oracle will do for WebLogic. Exactly how we do that for older versions is still under discussion. |
|
|