I completely agree with Jan’s view below. The specification document itself is a technical reference document and shouldn’t reference specifications not in the platform
(maintenance nightmare).
If we are strictly following a release train model we do not know what could be in the platform next release.
There are lots and lots of better ways to promote wider Jakarta EE specifications.
Jakarta EE Specifications | The Eclipse Foundation is the source of information of all specifications.
|
--
|
|
Steve
Millidge
Founder & CEO
|
From: jakartaee-platform-dev <jakartaee-platform-dev-bounces@xxxxxxxxxxx>
On Behalf Of Jan Westerkamp via jakartaee-platform-dev
Sent: Friday, August 11, 2023 12:15 AM
To: jakartaee-platform-dev@xxxxxxxxxxx
Cc: Jan Westerkamp <jan.westerkamp@xxxxxxx>
Subject: Re: [jakartaee-platform-dev] [DISCUSS] Introduce "favored specification" concept to Platform specification
I think this is an example of good intentions generating bad outcome:
"is this a good idea or not":
A specification is a technical document defining requirements on behaviour of technical implementation, that in must be expected or in some cases may be expected - in the best case this can be tested and certified
with the corresponding TCK.
Personas get addressed by a specification document are spec developers, implementation developers and interested, mostly experiences application developers - NOT POs, CEOs, CIOs etc.
To be clear: This is NOT a marketing or product management document to promote things - this is out of scope of a specification document!
When we do a good job, most developers and users don't even need to read it, they only need to read the digested form like a magazine article, blog post, Javadoc or listen a conference talk to apply the technology
in an intuitive way.
Additionally, with the intended release cadence of two years of the Jakarta EE Platform specification, such promoting information might outdate in an different, much shorter time frame.
We should do promoting on the Marketing Committee channels like the website to point out clearly, what is a mature or experimental technology besides the Platform and which version can be combined with which Platform
version instead. Using WG documents like the yearly Program Plan might be good too.
The specification should only contain in scope specs, otherwise what should be included then and where to stop? Jakarta stand-alone specs (which ones)? MicroProfile? Spring? Or regarding front-end technologies,
what about Vaadin?
To bring it in scope of the spec it need to be offered by the majority of the implementation vendors (push principle), the user demand (pull) or both (best case).
What is qualifying a sepc to be listed in the intended way? Developer survey result, WG Member voting, Committer or community voting, download rate?
Please let us add professional software engineer information into the spec document only and do industry politics somewhere else, while not mix up the scope of documents/channels!
"what should we call this thing":
The only thing I could imagine is adding an out-of-scope section to the spec and pointing out, that there is the Jakarta Platform spec with it's Profiles documented here and there is a wider set of Jakarta as
a platform in a sense of a set of technologies, that go beyond the Jakarta Platform spec itself, including additional specs. This section could give some clarification what is meant with "platform" and "sand-alone", which both are potential misleading names.
May be a (stable) link to theses specs listed (and maintained) on a website (https://jakarta.ee) could be added - but not more than that.
Everything else adds confusion and only blows up the spec document size for the intended users of it.
Am 10.08.23 um 15:50 schrieb Emily Jiang via jakartaee-platform-dev:
I support the idea to add such a section to drive some tractions to the standalone specifications. I don't feel we should say "Candidate xx" nor "Favored". I feel the wording like "Additional Specifications" might
be more appropriate.
I agree with the idea. There are some specs which obviously have some traction and have been released already or are close to having a 1.0 version but have not been included in the Platform.
I just don't like the term "favored". It sounds like they are already in the Platform and are just endorsed to use in the future (opposite of obsolete). I think it would be better to call them candidate, or incubator
specs, or something like that, to indicate they are active and considered for inclusion in the Platform in the future, while other specs are not ready to be considered to become part of the Platform yet. Or we could use both terms - candidate for the specs
considered for inclusion in the Platform, and incubator for the specs that are still not ready yet. Then we can easily promote both lists of specs without confusion.
> If we were to add a section like this, it would make sense to ask Platform implementations to mention in their CCR any such specs they implement so users can favor those Platform implementations.
I would go even further and mention the implemented favored/candidate specs, and maybe also other non-Platform specs, on the CCR summary page at
https://jakarta.ee/compatibility/certification/10/ so that people can easily compare which implementations provide which specs.
All the best,
Director, Jakarta EE expert
Omnifish OÜ, Narva mnt 5, 10117 Tallinn, Estonia | VAT: EE102487932
For discussion I'd like to separate the two aspects of "is this a good idea or not" and "what should we call this thing".
I like the idea. Another aspect for discussion is "what are the requirements for being listed."
Some high-level thoughts on being included:
- Specification is final (or will be when EE X is released)
- Specification can be implemented on EE X
- Specification TCK can run on EE X
The idea being we guide people to the exact versions of standalone specifications that have done work to ensure they can be implemented or run on EE X.
With that kind of definition, maybe simply calling them "Compatible Specifications" is apt. Not a firm name suggestion, just spit-balling.
If we were to add a section like this, it would make sense to ask Platform implementations to mention in their CCR any such specs they implement so users can favor those Platform implementations.
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
--
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
