I don't know what drug you took when dreaming that, but the delays of MVC had nothing to do with JAX-RS, and nobody ever wanted to write a 600 pager. JAX-RS compliance simply was not defined in terms of API+TCK but in terms of spec, a decade ago. We could have changed that already, but each time we discussed changing something we were told to wait, to not act, to not change, because everything must stay as it is, or will be decided by others shortly, is on the road, shall not be our focus, etc... So don't blame JAX-RS team, but blame the people deciding internals of Jakarta REST while being not involed in that actual work in any way. -Markus Von: jakarta.ee-community-bounces@xxxxxxxxxxx [mailto:jakarta.ee-community-bounces@xxxxxxxxxxx] Im Auftrag von Werner Keil
Gesendet: Freitag, 13. September 2019 11:00
An: Jakara EE community discussions
Betreff: Re: [jakarta.ee-community] Jakarta EE 8 Specs in PDF JAX-RS had a lot of problems it seems, long before e.g. Markus got involved. There were differences in the EG that caused members to resign. MVC on top of it was delayed multiple times and has a lot of catching up to do compared to the likes of Spring MVC. Last but not least Microprofile spawned off a REST Client Spec that at least partly competes with Jakarta REST outside Jakarta EE which adds even more confusion and places people have to look if they write an app that uses both. Jakarta EE tried to further embrace a Lean and Agile approach of "Working Software" over tons of documents. Other specs like Security now led by Arjan had this challenge, too and I think we found a good balance between writing things in a plain text document compared to JavaDoc of API, RI or TCK. We also had many terms to clarify, some especially with REST should be purged there in favor of the Security Spec, similar to other areas where CDI takes some responsibility in a central place. Overspecifying elements of the REST spec or writing a 600 page "novel" about parts that may not even be there much longer would be a waste of time. There are other specs that were better at this and the ones that had trouble in the past should try to learn from them. Reality is that in Jakarta REST we have a list of inconsistencies amon API/PDF/Spec, and our spec is far from being just a readme for the TCK. The truth is, the certification is against the SPEC, and the TCK is just a tool of automating it. And that tool simply has bugs, like any other software. -Markus Hi, In practice the vendors certify against the TCKs, which have all been transferred. The spec documents provide guidance and explanation on how to implement a compatible implementation, but ultimately it's the TCK that needs to be passed to certify compatibility. So of course the current situation is not ideal, but it's unlikely this is preventing any vendor from certification at the moment. As long as the TCK does not check rules laid out by the specs, it is in the best interest of those vendors to certify against these TCKs, because if we fix the TCKs their products would fail. So maybe we should simply make the TCKs completely empty to make more products pass them and have them in sync with the empty PDFs…? ;-) As long as the affected vendors employ the majority of committers and projects leads it is clear that they won't raise such a problem, isn't it? There is a reason why in politics we have such thing like "separation of powers". ;-) -Markus Steven, Bill and all the others in the Specification Committee know, we had a lot of last-minute discussion around TCKs that were problematic for certain products and implementations, especially Jakarta Faces or JSON Processing. We voted on on solutions to fix that. No such problem or need to vote was raised for Jakarta REST, so not sure, what the problem is, but it does not seem to harm vendors or their ability to certify against the TCK.
The problem is that now you have a different risk: Incompatible implementations. The reason is simple: The TCKs and APIs do not cover 100% of the rules laid out in the specs, so it now is possible to define an implementation as compliant with a spec, which actually is not. This risk is true at least for Jakarta REST as we already knew upfront of Jakarta EE several inconsistencies among API, TCK, spec and implementations that in fact do exist. We wanted to fix that, but where asked to not do fix it. And as certifications cannot be undone, we now started with a worst-case scenario: Having certified existing products against non-existent rules. Thanks! ;-( There are good legal reasons that the new specifications don’t point to the old specifications as this provides a clean, licensed, stand alone document to begin development from. In particular the new specifications are under a different license the EFSL https://www.eclipse.org/legal/efsl.php. If they referenced the requirements in the JCP documents then any user of the Jakarta specification would also be required to read the JCP document which has a different “click wrap” license which the user would then be required to accept and comply with. There was then a risk that this would require any Jakarta EE licensee to also become a Java EE licensee. IANAL Steve From: jakarta.ee-community-bounces@xxxxxxxxxxx <jakarta.ee-community-bounces@xxxxxxxxxxx> On Behalf Of Werner Keil
Sent: 12 September 2019 08:49
To: Jakara EE community discussions <jakarta.ee-community@xxxxxxxxxxx>
Subject: Re: [jakarta.ee-community] Jakarta EE 8 Specs in PDF Kevin, Thanks for the suggestions, I assume it'll help Markus or others in spec projects to point to the old specs till the new ones get beefed up or where they could not for some reason. I also have customers or agencies that still ask for J2EE experience after all these years. ;-) I stopped trying to correct them, but others who follow trends and new technologies or even try to shape them won't. We also see too many people who try to errect Confederate statues or deny the Holocaust or Climate Change, we should not make the same mistakes but rather look in the future. Markus,
Until the rest of the Specifications are contributed to Eclipse (soon, I hear...), why not just update your "front page" (wiki, gh pages, README, whatever) to point at the JCP page for background information? This could be a temporary stop gap until the Spec source is made available to you.
Also, Bill's comments (and everybody else on the Spec Committee) on the content of the skeletal specifications was to ensure consistency. If we provided a common template with common, consistent content (project name, scope statement, copyright, license, etc), then Jakarta EE will look and feel like a finished product. If we let every component do their own thing, then it would just look like a hodge-podge of information and would not provide the professional view that we have. You may not agree, and that's fine. But, we were doing this for a reason. Thanks.
---------------------------------------------------
Kevin Sutter
STSM, MicroProfile and Jakarta EE architect
e-mail: sutter@xxxxxxxxxx Twitter: @kwsutter
phone: tl-553-3620 (office), 507-253-3620 (office)
LinkedIn: https://www.linkedin.com/in/kevinwsutter
From: "Markus KARG" <markus@xxxxxxxxxxxxxxx>
To: "'Jakarta EE community discussions'" <jakarta.ee-community@xxxxxxxxxxx>
Date: 09/12/2019 06:20 AM
Subject: [EXTERNAL] Re: [jakarta.ee-community] Jakarta EE 8 Specs in PDF
Sent by: jakarta.ee-community-bounces@xxxxxxxxxxx
I know that. The question is, how shall the reader of the Jakarte EE 8 spec know? Von:Bill Shannon [mailto:bill.shannon@xxxxxxxxxx]
Gesendet: Mittwoch, 11. September 2019 23:08
An: Jakarta EE community discussions; Markus KARG
Betreff: Re: [jakarta.ee-community] Jakarta EE 8 Specs in PDF As Werner said, all the specs are on the JCP web site. You can find a list of all the specs and links to the JSRs on the Java EE Platform web siteor Oracle's Java EE web site. Markus KARG wrote on 9/11/19 11:06 AM: Actually it is hard for Jakarte EE 8 spec readers to find the Java EE 8 specs. The reason is that Bill Shannon (IIRC) enforced that existing references form the boilerplate specs to the Java EE specs have to get removed -- so we removed them, at least for JAX-RS. It is rather funny that now you say, people shall read exactly those specs… How shall they locate them? -Markus Von:jakarta.ee-community-bounces@xxxxxxxxxxx[mailto:jakarta.ee-community-bounces@xxxxxxxxxxx] Im Auftrag von Kevin Sutter
Gesendet: Mittwoch, 11. September 2019 10:59
An: Jakarta EE community discussions
Betreff: Re: [jakarta.ee-community] Jakarta EE 8 Specs in PDF Arjan is correct. We have complete Specifications for the Platform, Web Profile, CDI, and Bean Validation. The rest of the Components have these skeletal specifications and rely on the Javadoc for Jakarta EE 8. These other Specifications will be filed as they complete their copyright and IP clearances. We decided it was best to go this route instead of waiting for all of the Component specs to clear. Appreciate your patience.
I covered some of these process-related items in my "Jakarta for dummEEs" talk yesterday at the JakartaOne Livestream conference. Replays are available:
https://www.crowdcast.io/e/nztuljys/1
---------------------------------------------------
Kevin Sutter
STSM, MicroProfile and Jakarta EE architect
e-mail: sutter@xxxxxxxxxx Twitter: @kwsutter
phone: tl-553-3620 (office), 507-253-3620 (office)
LinkedIn: https://www.linkedin.com/in/kevinwsutter
From: arjan tijms <arjan.tijms@xxxxxxxxx>
To: Jakarta EE community discussions <jakarta.ee-community@xxxxxxxxxxx>
Date: 09/11/2019 09:34 AM
Subject: [EXTERNAL] Re: [jakarta.ee-community] Jakarta EE 8 Specs in PDF
Sent by: jakarta.ee-community-bounces@xxxxxxxxxxx
Hi,
It's "correct" in the sense that the real spec documents haven't been transferred yet. The current ones that are released (most of them) are just the bare minimum. We call them boilerplate specs.
We expect that sometime in the future the existing Java EE spec documents or a subset of those will be transferred.
Kind regards,
Arjan
On Wed, Sep 11, 2019 at 4:30 PM Gregor Kovač <kovica@xxxxxxxxx> wrote:
Hi!
Specs are available at https://jakarta.ee/specifications/
"Jakarta EE Platform 8" has 242 pages, but "Jakarta Enterprise Beans 3.2" has only 5 pages. Am I missing something? Looking in a wrong place, ... ?
Best regards,
Kovi
_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakarta.ee-community_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakarta.ee-community _______________________________________________ jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakarta.ee-community
_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakarta.ee-community
_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakarta.ee-community
_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakarta.ee-community
_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakarta.ee-community
_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakarta.ee-community
|
