Date   

Re: JSF 2.3 Table 5-3 JSF artifacts eligible for injection - Constructor Injection question

pnicoluc@...
 

I have the following JSF 2.3 Spec issue opened: https://github.com/javaee/javaserverfaces-spec/issues/1455

I'm working to open an issue with the EE8 platform spec. I'll post that in this thread once opened.


Re: JSF 2.3 Table 5-3 JSF artifacts eligible for injection - Constructor Injection question

pnicoluc@...
 

The Platform spec issue is here: https://github.com/javaee/javaee-spec/issues/62


Re: JSF 2.3 Table 5-3 JSF artifacts eligible for injection - Constructor Injection question

 

Hello Paul,

I secured some time to think about this today. If you like, you can
skip right to the CONCLUSION by searching for CONCLUSION:.

First, the general rationale for ctor injection is adequately described
in this stackoverflow post
https://stackoverflow.com/questions/19381846/why-use-constructor-over-setter-injection-in-cdi .
Given that rationale, ctor injection seems to make the most sense for
domain objects, rather than the classes in Table 5-3.

Let's take a look at each of the classes in Table 5-3 and ask ourselves
if it makes sense to have ctor injection for that class, and what it
would mean to have ctor injection. I will also suggest a potential use
for ctor injection for a future revision of JSF.

javax.el.ELResolver

Section 5.5.2.1 states "ELResolver instances have application lifetime
and scope." Since this is lifetime scope, we really don't know what
would make sense to pass to a ctor injection.

Future: Perhaps the presence of @Inject with an ELResolver argument
could be used to provide a reference to the parent ELResolver in the
chain.

javax.faces.application.ApplicationFactory

Section 7.2 states, "A single instance of
javax.faces.application.ApplicationFactory must be made available to
each JSF- based web application running in a servlet or portlet
container." Since this is a singleton, what would make sense to pass to
the ctor?

Also, this class is mentioned in section 11.4.7 Delegating
Implementation Support. In that section, the spec says, "For all of
these artifacts, the decorator design pattern is leveraged, so that if
one provides a constructor that takes a single argument of the
appropriate type, the custom implementation receives a reference to
the implementation that was previously fulfilling the role." So in
this sense we already support ctor injection for this class. Future
occurrences of this explanation will be labeled as "See 11.4.7
Delegating Implementation Support"

Future: Perhaps this @Inject could be passed the
javax.enterprise.inject.spi.CDI.

javax.faces.application.NavigationHandler

Section 7.4.1 states, "A single NavigationHandler instance is
responsible for consuming the logical outcome returned by an application
action that was invoked, along with additional state information that is
available from the FacesContext instance for the current request, and
(optionally) selecting a new view to be rendered." So, this is a singleton.

See 11.4.7 Delegating Implementation Support

javax.faces.application.ResourceHandler

This is also an application singleton. See 11.4.7 Delegating
Implementation Support.

See 11.4.7 Delegating Implementation Support

Future: Perhaps this @Inject could be passed the default
ViewDeclarationLanguage?

javax.faces.application.StateManager

Section 7.8 makes it clear the StateManager is an application
singleton, therefore ctor injection doesn't make a lot of sense.

See 11.4.7 Delegating Implementation Support

Future: Perhaps this @Inject could be passed the default
ViewDeclarationLanguage?

javax.faces.component.visit.VisitContextFactory

This is a singleton factory. I don't see what it would be useful to
pass for ctor injection.

See 11.4.7 Delegating Implementation Support

javax.faces.context.ExceptionHandlerFactory

This is a singleton factory. I don't see what it would be useful to
pass for ctor injection.

See 11.4.7 Delegating Implementation Support

javax.faces.context.ExternalContextFactory

Section 6.8 states, "A single instance of
javax.faces.context.ExternalContextFactory must be made available to
each JSF-based web application running in a servlet or portlet
container."

This is a singleton factory. I don't see what it would be useful to
pass for ctor injection.

See 11.4.7 Delegating Implementation Support

javax.faces.context.FacesContextFactory

This is a singleton factory.

Future: Since the default one simply turns around and calls the
exceptionHandlerFactory() and externalContextFactory, it would make
sense to allow these to be @Inject ctor injected, but that would be a
new feature.

See 11.4.7 Delegating Implementation Support

javax.faces.context.PartialViewContextFactory

Since this is an application singletion, I don't know it would make
sense to pass for ctor injection.

javax.faces.event.ActionListener

See 11.4.7 Delegating Implementation Support

javax.faces.event.SystemEventListener

This one is implemented by application code.

Future: Perhaps ctor injection could be passed the Application?

javax.faces.lifecycle.ClientWindowFactory

This is a singleton factory.

Future: the default impl gets a handle to the Application and
subscribes to the PostConstructApplicationEvent. Perhaps ctor
injection could be useful to pass the Application.

javax.faces.lifecycle.LifecycleFactory

This is a singleton factory.

Future: Perhaps this @Inject could be passed the
javax.enterprise.inject.spi.CDI.

See 11.4.7 Delegating Implementation Support

javax.faces.event.PhaseListener

These are application singletons.

Future: Perhaps ctor injection could pass a reference to the
Application, or the Lifecycle?

javax.faces.render.RenderKitFactory

This is a singleton factory.

Future: Perhaps ctor injection could pass a reference to the
Application.

See 11.4.7 Delegating Implementation Support

javax.faces.view.ViewDeclarationLanguageFactory

This is a singleton factory.

Future: Perhaps ctor injection could pass a reference to the
Application.

javax.faces.view.facelets.FaceletCacheFactory

This is a singleton factory.

Future: Perhaps ctor injection could pass a reference to the
Application.

javax.faces.view.facelets. TagHandlerDelegateFactory

This is a singleton factory.

Future: Perhaps ctor injection could pass a reference to the
Application.

CONCLUSION:

In conclusion I will propose the JSF maintenance lead to make the
following change to the spec.

In section 5.4.1, please change the text

In addition to managed beans being injectable in this manner, the
following JSF artifacts are also injectable.

to be instead

In addition to managed beans being injectable in this manner, the
following JSF artifacts are also injectable via field and setter
injection. Constructor injection does not make sense for these
artifacts and is not supported.

Thanks,

Ed


Maven Central download statistics for Mojarra

Neil Griffin
 

Dear friends of JSF,

Does anyone have the ability to get download statistics from Maven Central for Mojarra? I'm interested in seeing the download trends over the past year.

My best guess is that whoever has the username+password at Oracle for publishing artifacts has the ability.

It would be as simple as signing-in to https://oss.sonatype.org/ and clicking on "Central Statistics"

Thanks,

Neil


Re: 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:

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




notice: javaserverfaces/mojarra is read-only now

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



Re: notice: javaserverfaces/mojarra is read-only now

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


Re: notice: javaserverfaces/mojarra is read-only now

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,

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



Re: notice: javaserverfaces/mojarra is read-only now

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:
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:

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





Re: notice: javaserverfaces/mojarra is read-only now

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:

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:
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:

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






Re: notice: javaserverfaces/mojarra is read-only now

Bill Shannon <bill.shannon@...>
 

Hi Kyle.

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:

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:

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:
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:

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







Re: notice: javaserverfaces/mojarra is read-only now

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:
Hi Kyle.

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:
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:

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:
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:

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








Re: notice: javaserverfaces/mojarra is read-only now

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:

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:
Hi Kyle.

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:
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:

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:
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:

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









About the diff between 2.3 and master

ren.zhijun@...
 

Hi Arjan,

In our Github project javaserverfaces/mojarra, MOJARRA_2_3X_ROLLING branch is "119 commits ahead, 297 commits behind master".

What's the main differences between the two branches?  The merge from 2.3 to master will be very difficult cause you have done file structure refactoring, right?

For current donation to Eclipse, can we donate MOJARRA_2_3X_ROLLING instead of master branch? it means that 297 commits in master will not be donated to Eclipse, do you have concern about it?


Thanks,

Zhijun


Re: About the diff between 2.3 and master

Arjan Tijms
 

Hi,

The major difference between MOJARRA_2_3X_ROLLING and master are the number of patches Bauke and Kyle did while the vetting of the master was already in progress.

I think MOJARRA_2_3X_ROLLING can not just be donated, as it hasn't been vetted. All the license checks and removal of (non-compliant) libraries has been done in master.

The patches however should all be very focussed individual changes, and as they have been applied to MOJARRA_2_2X_ROLLING and before as well, I think it will be much easier to apply them one by one to the master at Eclipse.

Kind regards,
Arjan



On Fri, Apr 27, 2018 at 5:14 AM, <ren.zhijun@...> wrote:
Hi Arjan,

In our Github project javaserverfaces/mojarra, MOJARRA_2_3X_ROLLING branch is "119 commits ahead, 297 commits behind master".

What's the main differences between the two branches?  The merge from 2.3 to master will be very difficult cause you have done file structure refactoring, right?

For current donation to Eclipse, can we donate MOJARRA_2_3X_ROLLING instead of master branch? it means that 297 commits in master will not be donated to Eclipse, do you have concern about it?


Thanks,

Zhijun




Re: About the diff between 2.3 and master

Bill Shannon <bill.shannon@...>
 

My understanding is that the master isn't passing the JSF 2.3 TCK, perhaps because some API changes have been introduced?

Do you expect master to be JSF 2.3 compatible?

I think we would like to get master back to JSF 2.3 compatible so we can contribute it to Eclipse.  How difficult will that be?  The bug fixes that have been applied to the branch can either be applied to master now or can be applied to the Eclipse project after it's created.

arjan tijms wrote on 04/27/18 04:11 AM:

Hi,

The major difference between MOJARRA_2_3X_ROLLING and master are the number of patches Bauke and Kyle did while the vetting of the master was already in progress.

I think MOJARRA_2_3X_ROLLING can not just be donated, as it hasn't been vetted. All the license checks and removal of (non-compliant) libraries has been done in master.

The patches however should all be very focussed individual changes, and as they have been applied to MOJARRA_2_2X_ROLLING and before as well, I think it will be much easier to apply them one by one to the master at Eclipse.

Kind regards,
Arjan



On Fri, Apr 27, 2018 at 5:14 AM, <ren.zhijun@...> wrote:
Hi Arjan,

In our Github project javaserverfaces/mojarra, MOJARRA_2_3X_ROLLING branch is "119 commits ahead, 297 commits behind master".

What's the main differences between the two branches?  The merge from 2.3 to master will be very difficult cause you have done file structure refactoring, right?

For current donation to Eclipse, can we donate MOJARRA_2_3X_ROLLING instead of master branch? it means that 297 commits in master will not be donated to Eclipse, do you have concern about it?


Thanks,

Zhijun





Re: About the diff between 2.3 and master

Arjan Tijms
 

Hi,

On Fri, Apr 27, 2018 at 9:48 PM, Bill Shannon <bill.shannon@...> wrote:
My understanding is that the master isn't passing the JSF 2.3 TCK, perhaps because some API changes have been introduced?

The API project in master has not been touched, it's 100% identical to the 2.3 branch. 

But it's always possible an accidental bug has crept in the implementation project that causes faulty behaviour (this would have been my mistake then).

In this case, if I'm not mistaken, it's only a NullPointerException that's accidentally wrapped in a FacesException.
 
Do you expect master to be JSF 2.3 compatible?

Yes indeed, it should be fully 2.3 compatible. No behaviour (should) have been changed.
 
I think we would like to get master back to JSF 2.3 compatible so we can contribute it to Eclipse.  How difficult will that be?

I can only assume it should be easy. I'll take a look at the exception right away. The contribution to Mojarra has already been done, hasn't it? 

 
  The bug fixes that have been applied to the branch can either be applied to master now or can be applied to the Eclipse project after it's created.

I've just created an issue to track this effort: https://github.com/eclipse-ee4j/mojarra/issues/4380

I can apply the bug fixes to either repo (Oracle or Eclipse), but since the master has already been transferred I assume that Eclipse is easiest.

Please advise, so I can potentially start with this task this weekend.

Kind regards,
Arjan Tijms










 

arjan tijms wrote on 04/27/18 04:11 AM:
Hi,

The major difference between MOJARRA_2_3X_ROLLING and master are the number of patches Bauke and Kyle did while the vetting of the master was already in progress.

I think MOJARRA_2_3X_ROLLING can not just be donated, as it hasn't been vetted. All the license checks and removal of (non-compliant) libraries has been done in master.

The patches however should all be very focussed individual changes, and as they have been applied to MOJARRA_2_2X_ROLLING and before as well, I think it will be much easier to apply them one by one to the master at Eclipse.

Kind regards,
Arjan



On Fri, Apr 27, 2018 at 5:14 AM, <ren.zhijun@...> wrote:
Hi Arjan,

In our Github project javaserverfaces/mojarra, MOJARRA_2_3X_ROLLING branch is "119 commits ahead, 297 commits behind master".

What's the main differences between the two branches?  The merge from 2.3 to master will be very difficult cause you have done file structure refactoring, right?

For current donation to Eclipse, can we donate MOJARRA_2_3X_ROLLING instead of master branch? it means that 297 commits in master will not be donated to Eclipse, do you have concern about it?


Thanks,

Zhijun






Re: About the diff between 2.3 and master

Bill Shannon <bill.shannon@...>
 

Unfortunately there's too many people involved in this contribution process and not everyone is aware of everything that's going on.  That definitely includes me.

What was supposed to happen was we were supposed to quiesce the old project, produce a release (including verifying that it passes the TCK), and then transfer the project to Eclipse.

I was under the impression that we were having a discussion about which branch to transfer to Eclipse because we hadn't yet transferred anything and because the master branch wasn't passing the TCK.  If in fact we've already transferred the master branch and it's not actually passing the TCK, we need to fix that ASAP.  We may need to redo the transfer, or we may need to overlay fixes that are made to the old repository.

Please work with the rest of the Oracle team to apply any required fixes to the Oracle GitHub repository so that it passes the TCK and a new release can be made.  Then we can fix the Eclipse repository.

Thanks.


arjan tijms wrote on 04/27/18 01:06 PM:

Hi,

On Fri, Apr 27, 2018 at 9:48 PM, Bill Shannon <bill.shannon@...> wrote:
My understanding is that the master isn't passing the JSF 2.3 TCK, perhaps because some API changes have been introduced?

The API project in master has not been touched, it's 100% identical to the 2.3 branch. 

But it's always possible an accidental bug has crept in the implementation project that causes faulty behaviour (this would have been my mistake then).

In this case, if I'm not mistaken, it's only a NullPointerException that's accidentally wrapped in a FacesException.
 
Do you expect master to be JSF 2.3 compatible?

Yes indeed, it should be fully 2.3 compatible. No behaviour (should) have been changed.
 
I think we would like to get master back to JSF 2.3 compatible so we can contribute it to Eclipse.  How difficult will that be?

I can only assume it should be easy. I'll take a look at the exception right away. The contribution to Mojarra has already been done, hasn't it? 

 
  The bug fixes that have been applied to the branch can either be applied to master now or can be applied to the Eclipse project after it's created.

I've just created an issue to track this effort: https://github.com/eclipse-ee4j/mojarra/issues/4380

I can apply the bug fixes to either repo (Oracle or Eclipse), but since the master has already been transferred I assume that Eclipse is easiest.

Please advise, so I can potentially start with this task this weekend.

Kind regards,
Arjan Tijms










 

arjan tijms wrote on 04/27/18 04:11 AM:
Hi,

The major difference between MOJARRA_2_3X_ROLLING and master are the number of patches Bauke and Kyle did while the vetting of the master was already in progress.

I think MOJARRA_2_3X_ROLLING can not just be donated, as it hasn't been vetted. All the license checks and removal of (non-compliant) libraries has been done in master.

The patches however should all be very focussed individual changes, and as they have been applied to MOJARRA_2_2X_ROLLING and before as well, I think it will be much easier to apply them one by one to the master at Eclipse.

Kind regards,
Arjan



On Fri, Apr 27, 2018 at 5:14 AM, <ren.zhijun@...> wrote:
Hi Arjan,

In our Github project javaserverfaces/mojarra, MOJARRA_2_3X_ROLLING branch is "119 commits ahead, 297 commits behind master".

What's the main differences between the two branches?  The merge from 2.3 to master will be very difficult cause you have done file structure refactoring, right?

For current donation to Eclipse, can we donate MOJARRA_2_3X_ROLLING instead of master branch? it means that 297 commits in master will not be donated to Eclipse, do you have concern about it?


Thanks,

Zhijun







Re: About the diff between 2.3 and master

ren.zhijun@...
 

Hi Arjan,

Then you will fix the TCK issue in javaserverfaces/mojarra project, I will un-archive the project for your fix commit.( you need to file PR and approve it by yourself)

Then you will do the merge from MOJARRA_2_3X_ROLLING to master, right? 

Hi Bill,

From which project (Oracle Github or Eclipse Github) shall the release be for EE8/GF5.0 TCK test?

The merge(from MOJARRA_2_3X_ROLLING to master) shall also be done in Oracle repo first and then overlay the fix to Eclipse repo, right? 


Thanks,

Zhijun


On 28/04/2018 8:19 AM, Bill Shannon wrote:
Unfortunately there's too many people involved in this contribution process and not everyone is aware of everything that's going on.  That definitely includes me.

What was supposed to happen was we were supposed to quiesce the old project, produce a release (including verifying that it passes the TCK), and then transfer the project to Eclipse.

I was under the impression that we were having a discussion about which branch to transfer to Eclipse because we hadn't yet transferred anything and because the master branch wasn't passing the TCK.  If in fact we've already transferred the master branch and it's not actually passing the TCK, we need to fix that ASAP.  We may need to redo the transfer, or we may need to overlay fixes that are made to the old repository.

Please work with the rest of the Oracle team to apply any required fixes to the Oracle GitHub repository so that it passes the TCK and a new release can be made.  Then we can fix the Eclipse repository.

Thanks.


arjan tijms wrote on 04/27/18 01:06 PM:
Hi,

On Fri, Apr 27, 2018 at 9:48 PM, Bill Shannon <bill.shannon@...> wrote:
My understanding is that the master isn't passing the JSF 2.3 TCK, perhaps because some API changes have been introduced?

The API project in master has not been touched, it's 100% identical to the 2.3 branch. 

But it's always possible an accidental bug has crept in the implementation project that causes faulty behaviour (this would have been my mistake then).

In this case, if I'm not mistaken, it's only a NullPointerException that's accidentally wrapped in a FacesException.
 
Do you expect master to be JSF 2.3 compatible?

Yes indeed, it should be fully 2.3 compatible. No behaviour (should) have been changed.
 
I think we would like to get master back to JSF 2.3 compatible so we can contribute it to Eclipse.  How difficult will that be?

I can only assume it should be easy. I'll take a look at the exception right away. The contribution to Mojarra has already been done, hasn't it? 

 
  The bug fixes that have been applied to the branch can either be applied to master now or can be applied to the Eclipse project after it's created.

I've just created an issue to track this effort: https://github.com/eclipse-ee4j/mojarra/issues/4380

I can apply the bug fixes to either repo (Oracle or Eclipse), but since the master has already been transferred I assume that Eclipse is easiest.

Please advise, so I can potentially start with this task this weekend.

Kind regards,
Arjan Tijms










 

arjan tijms wrote on 04/27/18 04:11 AM:
Hi,

The major difference between MOJARRA_2_3X_ROLLING and master are the number of patches Bauke and Kyle did while the vetting of the master was already in progress.

I think MOJARRA_2_3X_ROLLING can not just be donated, as it hasn't been vetted. All the license checks and removal of (non-compliant) libraries has been done in master.

The patches however should all be very focussed individual changes, and as they have been applied to MOJARRA_2_2X_ROLLING and before as well, I think it will be much easier to apply them one by one to the master at Eclipse.

Kind regards,
Arjan



On Fri, Apr 27, 2018 at 5:14 AM, <ren.zhijun@...> wrote:
Hi Arjan,

In our Github project javaserverfaces/mojarra, MOJARRA_2_3X_ROLLING branch is "119 commits ahead, 297 commits behind master".

What's the main differences between the two branches?  The merge from 2.3 to master will be very difficult cause you have done file structure refactoring, right?

For current donation to Eclipse, can we donate MOJARRA_2_3X_ROLLING instead of master branch? it means that 297 commits in master will not be donated to Eclipse, do you have concern about it?


Thanks,

Zhijun








Re: About the diff between 2.3 and master

Bill Shannon <bill.shannon@...>
 

ren.zhijun@... wrote on 04/27/2018 07:29 PM:

Hi Bill,

From which project (Oracle Github or Eclipse Github) shall the release be for EE8/GF5.0 TCK test?

Oracle GitHub.

The merge(from MOJARRA_2_3X_ROLLING to master) shall also be done in Oracle repo first and then overlay the fix to Eclipse repo, right? 

Yes.

Thanks.

41 - 60 of 64