[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [jakartaee-platform-dev] : Re: Pushing RCx or Mx to maven central
|
Some history here for everyone's benefit.
The short version is when it comes to certification, the API jar is the responsibility of the implementation.
In the early days everyone created their own API jars. The first open source API jars to hit Maven Central came from Apache Geronimo around 2004 under the ALv2 license and org.apache.geronimo.spec package. When GlassFish came round their API jars also hit Maven Central. I think that was around 2006, under CDDL and org.glassfish. Those eventually were renamed to the javax groupId, despite that some APIs are also implementations such as JavaMail and Activation and others like Apache did have compatible and equivalent implementations.
When we launched Jakarta and did our first releases, those same API jars still containing some implementations, were shipped to Maven Central under the jakarta.* groupId.
As time has gone on, fewer and fewer of us are creating our own unique API jars. It still remains true, however, that providing API classes is the responsibility of the implementation. The API jars we in the spec process are largely for convenience and to help verify we have a complete and implementable spec. They're useful for people to compile against and are equally helpful to vendors, but there is not a singular "official" API jar. Any API jar that passes the signature tests is equally official.
--
David Blevins
http://twitter.com/dblevins
http://www.tomitribe.com
310-633-3852
> On Jan 13, 2022, at 9:26 AM, Thomas Watson <tjwatson@xxxxxxxxxx> wrote:
>
> I'm unsure I understand the implications of what you state Mike. For a specification to go final it needs at least one compatible implementation is required. For an implementation to claim it is compatible it needs to pass with the final released TCK. There is an obvious chicken and egg issue with that statement. In another specification working group I am involved in we worked with the Eclipse Foundation to come up with these steps that we thought worked through the chicken and egg issue:
>
> 1) WG publishes RC versions of the API to maven central
> 2) Implementations build based of the RC versions APIs in maven central
> 3) Implementation publishes their RC impl to maven central
> 4) WG submits ballot that points to one or more compatible implementations in maven central that pass the final TCK
> 5) WG submits final APIs to maven central after final release is done
> 6) Implementation projects build off final APIs and release final implementations at their leisure.
>
> Is that a legitimate flow for getting a specification release done? I'm more asking that for my own information than trying to force this flow on the Jakarta WG.
>
> Tom
>
>
>
> ----- Original message -----
> From: "Mike Milinkovich" <mike.milinkovich@xxxxxxxxxxxxxxxxxxxxxx>
> Sent by: "jakartaee-platform-dev" <jakartaee-platform-dev-bounces@xxxxxxxxxxx>
> To: jakartaee-platform-dev@xxxxxxxxxxx
> Cc:
> Subject: [EXTERNAL] Re: [jakartaee-platform-dev] : Re: Pushing RCx or Mx to maven central
> Date: Thu, Jan 13, 2022 10:39 AM
>
> On 2022-01-13 11:35 a.m., Nathan Rauh wrote:
>> I hope you are not suggesting that compatible implementations certify on a forked copy of the API rather than the official Release Candidate or Milestone artifact. That does not sound like a legitimate certification.
> At the risk of stating the obvious, even an "official Release Candidate or Milestone" does not provide a "legitimate certification". Compatibility claims can only be made based on released binaries under the Eclipse Foundation TCK License.
>
> Of course we all hope that much testing happens using release candidates and milestones :)
>
>
>
>
> This email has been checked for viruses by Avast antivirus software.
> www.avast.com
>
> _______________________________________________
> 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
