Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakarta.ee-spec.committee] [SUMMARY] Implementations requirements

To answer the question from a Payara perspective RE: contributing sufficient resource. I believe the answer is simply; 


If we have sufficient resources to contribute to EE4J, and GlassFish to keep it relevant as a Compatible Implementation of the Jakarta EE Platform then we will do so. Whether we have sufficient resources will depend on a lot of business factors and is not a given.


One of the key factors will be the level of Eclipse Foundation and Jakarta EE working group membership and brand license fees required to ensure Payara Server and Payara Micro can be Compatible Implementations of the Jakarta EE Platform. The second key factor is the legal regime we end up with at the end of this process and finally as always the resources we have depend on the willingness of the community and customers to pay for subscriptions to open source implementations of Jakarta EE. Always a challenge. 


Steve


From: jakarta.ee-spec.committee-bounces@xxxxxxxxxxx <jakarta.ee-spec.committee-bounces@xxxxxxxxxxx> on behalf of Mike Milinkovich <mike.milinkovich@xxxxxxxxxxxxxxxxxxxxxx>
Sent: 23 June 2018 4:02 PM
To: jakarta.ee-spec.committee@xxxxxxxxxxx
Subject: Re: [jakarta.ee-spec.committee] [SUMMARY] Implementations requirements
 
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


--
Mike Milinkovich
mike.milinkovich@xxxxxxxxxxxxxxxxxxxxxx
(m) +1.613.220.3223



Avast logo

This email has been checked for viruses by Avast antivirus software.
www.avast.com


Back to the top