The RichFaces and Seam teams are nothing if not passionate about community, open source, and working with standard bodies like the Java Community Process (JCP). That is one of the reasons that Oracle/Sun's decision to disband the JSF expert group (JSR-314) with no successor JSR filed under which to develop future revisions of JSF is disappointing. Dan Allen summed up JBoss/Red Hat's position quite clearly in his letter to the JSR-314 public mailing list. While we want to continue supporting the JSF specification, not having an official JSF and EG, along with the intellectual property and governance guarantees this brings, makes this very difficult.
I want say something very clearly. I believe that the individual engineers are doing the best they can with their current priorities and constraints. They are still posting to the JSR-314 open mailing list, which you can view using the JBoss jsr-314-open-mirror), and asking for comments and patches. The RichFaces and Seam teams will also work within our current constraints and will work to resolve some of the core issues that will impact key features of JSF 2.0. While at the same time we will be pushing for a new JSR to be formed. Unfortunately, due to the above mentioned issues, JBoss's participation is limited, although we are fully prepared to contribute if the correct environment is present. When it isn't, we can only expect the spec leads to take on board our issues and push them.
As an example of the above, one of the major goals of the JSF specification is to enable component libraries to interoperate with each other within the same application, and ideally the same page. As component libraries develop to the new specification, and add features, we are finding areas where the specification needs to be updated. As there is no official JSR, and the specification priorities are driven by the RI priorities, some of these issues have been pushed to future versions of the specification ( with an unknown timeline ). Take for example #658 which deals with a problem with the PartialViewContext and how component libraries can extend it without breaking other component libraries. The RichFaces team has provided a draft patch to resolve this (thanks Nick) , however due to timing this will not be included in JSF 2.1.
With no known timeframe, JSR or expert group in place for JSF 2.2+ the Seam and RichFaces projects will continue to give our communities the features and functionality they expect, but in some cases this will need to be outside of the JSF specification. For example View Actions will be implemented by Seam Faces instead of being part of the specification for now. Richfaces has and will continue to reach out to other component libraries such as IceFaces, PrimeFaces, etc… to kick off discussions on how to address these issues outside of the specification. Hopefully we'll be able to deliver the interoperability that was promised, while prototyping updates for future versions of the specification.
Let's hope this situation can be resolved as soon as possible!
I'd also like to add that the situation with the JSR-314-OPEN mailinglist is another whole fiasco that has been a major source of frustration for us.
The long story short is that when the JCP updated the software on jcp.org last year, the archiving and registration mechanism broke. At that point, the mailinglist ceased to be open because there were no archives available and no way to join. The mailinglist was never truly open in the first place because it required logging into a web interface just to read the archives. And it's the worst mailinglist interface I've ever used.
After a lot of phone calls, the JCP came back with a ridiculous manual process for registration and still didn't address the broken archives. I was made to look like a fool because I promised a lot of people I would get it fixed, yet was failing to do so.
At that point, I spent less than one day setting up a mirror of JSR-314-OPEN at JBoss. The archives are available from the day I set that up. So at least we have something, including my letter stating that Red Hat won't sacrifice its principles by participating without a proper process in place.
The whole situation with the mailinglist is such a comedy of errors. It's clear the JCP doesn't know the first thing about openness, or they aren't committed to it. Otherwise, that mailinglist would have been fixed a long time ago.
I apologize for sounding irritated. I get much more satisfaction from being positive. But I really have tried super hard to make this right, and I just don't know what else to do other than to explain what I've been through.
What about waiting first for the JCP Elections, then for the JavaSE JSRs and then, after we cross those bridges successfully, we can tackle this one?
Hello, I'm curious to see the patch for issue 658. It's not attached to the issue. Can you please attach it?
Thanks,
Ed
Wouldn't a collaboration of the JSF libraries providers outside the JCP be more productive? As I see it, the JCP just holds back the progress with its cumbersome procedure.
You could start a new open source project of a new library that will combine the RI and the specifications, and it will be a dependency for all the component libraries, so there won't be any fragmentation. I suspect you will be able to progress much faster this way than you would under the JCP.
I regret having to sound impatient, but all I've been told is to wait. Wait for the JCP to call me back, wait for the jcp.org infrastructure to get revamped (in late 2009, after the archives had been broken for > 6 months), wait for Java EE 6 to be done, wait for the Oracle acquisition to complete and now wait for the JCP to get sorted out. To put it frankly, we can't wait any more. Something needs to happen.
I'll cite the most significant reason why the mailinglist interface is so bad to backup my statement. It's almost impossible to link to an individual message. I say almost because if you view the source you can figure out how to create a direct link, but it's really kludgey. Actually, it's torture to progress.
As it stands today, that's really the only option we have.
Yes, but we had hoped to work through some of the low level issues if they were known. In the end it came down to what it always comes down too; priorities, and timing.
We'll continue to work with other component projects on interoperability, and I'm guessing get some of what we work on standardized into future versions.
I think the real call-to-arms of my blog is about getting the process updated, so that Expert Groups, and JSRs are not disbanded when the first version of a spec is released. Its an iteration, not a conclusion!
Iteration is absolutely the fitting word here. That's central to any software process, standards or otherwise.
I understand why you are impatient and tired of waiting. The timing of raising this, though, is not very good; I've already seen this post interpret as :-(, which, given the huge investment that Oracle has in ADF is senseless, but sensationalism sells newspapers (or gets hits).
By all means grill Oracle/us, but it will be much better for all of us, if you wait until after we get past the JavaSE votes...