Red Hat believes there are several operational and process issues that are inconsistent with the distributed, open source development model that Jakarta uses to create component and especially profile and the platform specifications. First I'll list the issues and then discuss why they seem problematic.
- A specification must identify at least one compatible open source implementation that fulfills all the requirements of the TCK. Today in the platform call we were also referencing a need to meet optional features, but this language is removed from the current 1.3 EFSP.
- Specification non-final artifacts tend to only be staged in the Jakarta repo rather than released to maven central, or not even produced.
- There is no/minimal distinction between ratifying a specification and certifying a compatible implementation for full branding usage rights.
- TCKs developed by specification projects often refer to downstream specifications (in the sense of strict API dependencies).
- The Web Profile and Platform TCKs use technologies that are considered either obsolete or not mainstream.
1 is the most ingrained behavior that has been practiced since the start of Java EE. Our fundamental problem with this is that is requires one project to align its development schedule to the Jakarta EE schedule. That was fine when there was a reference implementation notion. It is not a viable project management approach when you have disjoint resource sets developing specifications and TCKs that have to coordinate on an implementation. It is inefficient and hectic, especially on the profile and platform specs. The stated reason for why this is necessary is that it is the only way you know that the specifications are implementable. We argue that a composition of implementation achieve the same purpose, and do so with a higher density and quality of tests because you care about that in the context of each team that developed the TCK for a given implementation. With one implementation what tends to happen is creation of the minimum number of tests to validate integration.
2 is largely a project consistency issues. Some projects put out several milestone to maven central, others none. A general problem for Red Hat is that we need permanent content in blessed repos with source. The Jakarta staging repo fails on two criteria. We need a general operational policy that produces at least one public milestone before the final artifacts are staged.
3 is questioning the current rationale for 1 and questioning why the point 0 release has tended to be the only release. We should be more flexible in producing service releases of specs, apis and TCKs to facilitate a release early and often mindset around a given major/minor theme.
4 comes about because a given component technology desires to describe its relationship to existing technologies, but there is no project structure or consistent TCK framework that allows for this to be developed as a profile or platform TCK add-on.
5 is one of the worst aspects of the Jakarta project and impacts productivity on several levels. In our minds this really has to be the priority post EE 10 as it not only feeds into solutions for the previous 4 issues, it affects quality and an ability to attract participation at a very visceral level.
None of these can be addressed for EE 10. They need to feed into the retrospective and need to be priorities of the working group members to improve the viability of the project.
Scott Stark
Red Hat
