This is my attempt to try to summarize
this discussion and express my views on this topic. These are my
personal views and not any official position of the Eclipse
Foundation.
- I think that it would be damaging to the brand value of
Jakarta EE to abandon the concept of a Platform.
- I think that a Specification with zero Compatible
Implementations is not a very interesting specification. And
that statement applies as much to Profiles and Platforms as it
does to individual Specifications.
- Eclipse Glassfish is currently "the" Compatible
Implementation for the Platform Specification. There is no
rule that states that this status quo must continue forever.
If another implementation under the listed Open Source
Licenses hosted elsewhere stepped forward, I don't think that
there is anything preventing that from happening. Personally,
that would make me sad because the Eclipse Foundation is first
and foremost an open source community, and we like it when our
projects are successfully and broadly adopted. But only time
will tell whether Glassfish survives as a viable open source
project.
- I notice Bill Shannon's comments that Oracle's formal
position is different than Dmitry's personal one. But Dmitry
did state that "Many projects implementations were maintained
by Oracle and it’s an open question who will support them
after moving to EE4J." Which leads me to a question: as the
code is moved into EE4J from Oracle, is this a "dump and run"?
I.e. Is Oracle planning to contribute sufficient resources to
keep these projects moving forward? I do understand the
business pressures that incent the movement of resources to
other needs, but I wasn't under the impression that the
"community" was going to be wholly responsible for all future
maintenance of these projects effective immediately.
- @Richard - yes, I do think that when the time is right
separating Glassfish from the spec activities of EE4J makes
sense. Now that we are removing the requirement for a
reference implementation it feels obvious that Eclipse
Glassfish and its components should not be somehow made
special. But that is definitely not true until after we
ship Eclipse Glassfish 5.1 as Java EE compatible. So given
everything on our plates, I don't see the value in
restructuring until sometime after that release is complete.
I would love to hear from Oracle, Payara and Fujitsu as to
whether they intend to contribute sufficient resources to EE4J
and Glassfish to keep it relevant as a Compatible Implementation
of the Jakarta EE Platform.
On 2018-06-19 10:51 AM, Dmitry Kornilov wrote:
Hi,
I met some spec committee members on EclipseCon France and discussed my concerns about the spec process. I am starting this thread to discuss it with wider audience.
Here are my suggestions:
1. To achieve yearly platform release cadence we should get rid of the platform implementation and make specs implementations optional.
Developing an implementation requires time and resources. Many projects implementations were maintained by Oracle and it’s an open question who will support them after moving to EE4J. It can become a platform release blocker.
Another uncertainty is the platform implementation. It’s questionable that GlassFish will stay as Jakarta EE spec implementation. It’s used by Payara and Fujitsu. Other vendors are not interesting in it. Will Payara and Fujitsu be able to support and maintain it? As it is now the platform cannot be released without one implementation passing all TCK tests. It may also become a release blocker.
Another (different from GlassFish) platform implementation may replace GlassFish. It can be Open Liberty, for example. In this case one vendor takes the dominant leader position (IBM in Open Liberty case) which may not be accepted well by the community.
Solution to this problem is removing the implementation requirement from the spec process. The spec implementations become 'nice to have' instead of 'must have’. During the spec review process the spec committee (or the platform project) decides if implementation required or not. The decision should be made based on risks analysis and agreements from vendors to implement it in future. The platform implementation also becomes optional. Vendors will release their implementations after the platform API is released.
If not requiring spec implementations sounds too strong we can agree to get rid of the platform implementation only.
The disadvantage of this plan is that without the implementation, it’s not guaranteed that the spec is implementable. To address it we should have a well defined process of specs and TCKs modifications.
2. TCK challenges support plan
Because the implementation can be developed after the API release, the spec process must guarantee that TCK challenges are solved as quick as possible. It must specify the response times from spec project teams. Also, the spec process has to define what is done if challenge is accepted and new version of TCK and possibly the spec needs to be released.
Please make your comments.
Thanks,
Dmitry
_______________________________________________
jakarta.ee-spec.committee mailing list
jakarta.ee-spec.committee@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jakarta.ee-spec.committee
|
This email has been checked for viruses by Avast antivirus software.
www.avast.com
|
|