Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ee4j-pmc] Servlet API kickoff
I can't reply officially for the PMC since I'm not on the PMC, but I thought I'd take a stab at offering my expectations of answers to these questions.  I'm sure the PMC will correct anything I got wrong.

Greg Wilkins wrote on 06/11/18 02:36 AM:

  • Are we also responsible for: the servlet 4.0 document; The relevant xml schemas; The TCK; The reference implementation?
There's two kinds of answers to "we" - "which people" and "which project".

The Eclipse Project for Servlet is responsible for the Servlet specification.  Our current expectation is that the Servlet specification document will not be contributed to Eclipse, so the Eclipse Project for Servlet will need to decided how to recreate the document from scratch or create a separate spec "addendum" document to allow evolving the spec going forward.

The Eclipse Project for Servlet is also responsible for the Servlet API classes, from which the Servlet API javadoc is generated, which is logically part of the Servlet specification.

Currently most of the Java EE schemas are managed in a separate repository, which will be contributed as part of the Eclipse Jakarta EE Platform project, which has not yet been created.  That project will be responsible for the schemas unless the PMC and the projects agree to change that.

The Servlet TCK is currently part of the CTS, which will be contributed to the Eclipse Jakarta EE TCK project.  There's strong interest in splitting the TCKs out of that project and into their own repositories, although at this point it's unclear who will do that work.  The current thinking is that, when that is done, the individual TCKs will be in projects of their own.

The Servlet reference implementation is part of the Eclipse GlassFish project.  (Note that there will not be a concept of "reference implementation" going forward, but instead there will be possibly many "specification implementations", of which GlassFish would be one.  At least one specification implementation will be required to release a new version of a spec.)

So, as you can see, there's lots of projects involved in managing "Servlets".  Obviously, coordination will be needed across all of those projects as the Servlet spec is evolved.  A simple way to manage that coordination would be to have the same people involved in all of those projects, so that (for example) the person who changes the Servlet API is also the person who changes the implementation to support the changed API and who also writes the test to test the changed API.  Obviously this won't be feasible or desirable in all cases, so the Project Leads for the projects and the PMC will need to decide how to best coordinate the people involved in these projects.

  • Can we make ammendments to the 4.0 javadoc and specification in our initial releases?  Ie can this be a maintenance release?
The goal is that the first release, Jakarta EE 8, is exactly the same as Java EE 8.  I suppose the PMC should decide whether it wants to allow "errata" to the spec for this first release.

  • What rules will our EG operate under?  IETF style?
As Mike described, the specification process is still being defined.

  • Is there an EE4J architect?
Not as far as I can tell, although to some extent the PMC plays that role, as do the Project Leads for the (not yet created) Eclipse Jakarta EE Platform project.

The servlet-dev@xxxxxxxxxxx mailing list is the mailing list for the Eclipse Project for Servlet.  The Project Leads, with guidance from the PMC, can decide whether and how to use that mailing list.  So far, the PMC seems to be letting the projects decide on their own what communication methods they want to use.

  • Do we keep everything on github?
Generally, yes.  The PMC has not yet provided any guidance on what should be included on the project page or on other eclipse.org pages.

  • Who has commit access to the repo? Why can’t we see who has access?
It should be all project Committers.

  • How is the TCK going to be managed? Where will the resources be provided from?
You mean who's going to write the tests?  That's TBD, but I'm quite sure that Oracle will not be writing most tests going forward.  As leader of the Servlet spec, you should be looking to recruit people to help write tests if you're not able to do it yourself.

  • How is the specification document going to be managed? Where is the source? What format?
As described above, we're most likely not going to be able to contribute the specification document.

  • What are the RI plans? Glassfish? Servlet only? Do we need one?  Who maintains?
The RI is GlassFish.  The only GlassFish plan so far is to release a version from Eclipse that is both Java EE 8 and Jakarata EE 8 compatible.  Beyond that, you'll either need to provide resources to evolve the RI, recruit new people to evolve the RI, or coordinate with existing Committers to the Eclipse GlassFish project to evolve the RI.

If you want a standalone Servlet RI, you'll need to figure out how to produce it.

  • Do we manage our own schemas?
Sort of.  Since the schemas will be in the Eclipse Jakarta EE Platform project, you'll either need to be a Committer on that project, or coordinate with the Committers to have changes made.  The changes should be largely driven by the Eclipse Project for Servlet, but note that with Java EE we were careful to coordinate such changes with the other platform schemas; I would expect the Eclipse Jakarta EE Platform project to help with such coordination.

The schema is logically part of the spec, despite being managed by a separate project.

  • What should the copyright headers be? Can we change them?
They're defined by Eclipse and included in the contributed code.  You should not change them except as authorized by Eclipse.


I hope that helps.  Let me know if you have more questions.

Back to the top