Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakartaee-platform-dev] [DISCUSS] Introduce "favored specification" concept to Platform specification
Hi,

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.

Best,
Jan



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.

Thanks
Emily


On Thu, Aug 10, 2023 at 9:28 AM Ondro Mihályi via jakartaee-platform-dev <jakartaee-platform-dev@xxxxxxxxxxx> wrote:
Hi,

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,
Ondro Mihalyi

Director, Jakarta EE expert
OmniFish - Jakarta EE Consulting & Support | www.omnifish.ee
Omnifish OÜ, Narva mnt 5, 10117 Tallinn, Estonia | VAT: EE102487932

On Thu, Aug 10, 2023 at 4:21 AM David Blevins via jakartaee-platform-dev <jakartaee-platform-dev@xxxxxxxxxxx> wrote:
On Aug 9, 2023, at 5:26 PM, Edward Burns via jakartaee-platform-dev <jakartaee-platform-dev@xxxxxxxxxxx> wrote:

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


--
Thanks
Emily


_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev


Back to the top