Hi everyone,
While the transfer is technically still in progress for JSF / Mojarra, the code has been available on Github for some time now, and some work has already started.
The proposed theme for the next version is doing away with legacy things that have crept up over the years. As such the proposed new version number is *3.0*.
One of the initial things to be removed is JSP support. I've talked about this with various people individually over the last year and with few exceptions this change was welcomed. JSP support has practically been deprecated ever since JSF 2.0 was released, and for some time newer features in JSF were explicitly not supported in JSP. I think it's indeed time we let go of this old beast.
Note that JSP is still absolutely fine to be used by it self (outside JSF), but for JSF it has never been a good match.
The second thing to be removed is the native managed bean system. JSF 2.0 already came with a warning that one day the parallel effort in the JCP to create a separate managed bean system (now known as CDI) would take its place. Between 2.0 and 2.3 support for this native managed bean system was already diminished. Flows for example used CDI beans exclusively, and in JSF 2.3 the managed bean package was deprecated. In JSF 2.3 CDI based alternatives were introduced for the last remaining unique features of the native managed bean system. Issues about various improvements for this native managed bean system were closed a long time ago with the explanation that CDI was the way forward.
For 3.0 I think it's now time to let this go as well.
Furthermore, there's a variety of other deprecated stuff within JSF, for instance remnants of the ancient native _expression_ language that JSF once had. I'd like to remove these as well.
Another candidate for removal may be the full state saving mechanism. Ongoing support for this was once needed to allow older component libraries to work on JSF, but since partial state saving has been around since 2.0 as well, it may be time to let go of this one too.
As for new features; an overhaul of the component system has been mentioned a couple of time, as well as some kind of unification for the iterating datable / repeat components. I'd personally like to add a simple option to allow extensionless URLs (e.g. just a single boolean in @FacesConfig).
Browsing the open issues and specifically reading the very old comments about JSF, the way to add faces messages could be much improved too. Whether this would be based on how OmniFaces currently makes this easier or whether some other way is more fitting for the core JSF API has yet to be decided by this group.
Possibly we could use the JDK 9 module system to officially modularise JSF. Maybe start with a bare core system, and then have things like navigation rules, flows, resource contracts, Facelets, etc eventually as separate modules on top of those.
There's probably a number of other features that members of this group would like to bring forward, but I hope the above mentioned things would be a good start.
We'd also have to agree to a few rules regarding commits. I'd don't like to complicate this too much, but for now I propose the following:
1. No direct commits to master. Commits should always be done via pull requests, where the PR has a clear name. Recommended is to create a new branch from your own fork for each PR.
2. A PR should be reviewed. GitHub has the review mechanism for that. Each PR should have at least one approval (+1) from another committer. If there's an explicit disapproval (reject/-1) from a committer the concerns must be addressed. If there's a stalemate (hopefully never happens) the project lead (currently me) breaks the tie.
3. There should be a "reasonable" time to allow for reviews. This time starts at the moment the PR is done. Approvals which are done do not reset this time. The purpose of this is to allow anyone to do a disapproval (reject/-1). I'd like to leave the definition of reasonable time open to the individual committers, but as a guideline I propose a minimum of 1 working day for any commit, 2 working days for a more complex commit (involving multiple files and complex logic) and 3 working days for huge commits (which by themselves should not happen too much)
Since in git we can always revert commits and/or amend them, I'd like to leave the definition of "complex" and "huge" open for now. In case that this becomes problematic we can always revise this.
As an extra note; we can't currently release the JSF API (with changes in the javax.* packages), but if I understood correctly Mojarra builds (the impl packages without the API) can be released. This is due to ongoing legal discussions. There's also no spec document transfer yet and no TCK transfer. Whether the spec document will ever be transferred is not certain yet.
Hope this is enough to gets us started!
Kind regards,
Arjan
