Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakartaee-platform-dev] [jakarta.ee-spec.committee] Updating Compatible Implementation brands
Hi,

Perhaps it’s helpful to see what I did for the WaSP project, which is the previous “JSP API/impl”.

There’s a handful of implementations like that in various API projects. In another email thread I think Amelia volunteered that Tomitribe would pick up some of these.

Essentially the work is:

* Create a new project at Eclipse EE4J
* Copy code from (most often) /impl folder in existing API project to new project
* Set up the CI for new project (copy over script from
API, remove API bits)
* Adjust API project CI to not build impl anymore 
* (Notify downstream projects to change their dependency)

@David, since you are already engaged with _expression_ Language, shall I assign that one to you? 
Or @Jean-Louis, would you like to take this one on?
Alternatively there’s also JSTL to be done.

Kind regards,
Arjan

On Wednesday, February 10, 2021, Jean-Louis Monteiro <jlmonteiro@xxxxxxxxxxxxx> wrote:
Thanks Werner.

It really means we need to get better in terms of consistency.
And it does not seem to be undoable.

I'd go with something simple
(Eclipse | Glassfish) spec version

Glassfish Concurrency 2.0.0
Eclipse Activation x.y.z
Eclipse Mail 2.0.0
Glassfish JSON Processing 2.0.0

No Jakarta, no CI.
Simple and consistent.

On Thu, Feb 4, 2021 at 4:40 PM Werner Keil <werner.keil@xxxxxxx> wrote:

I don’t think Steven is missing any permissions on a particular GH repository nor does it seem necessary to rename those, the issue some feel uncomfortable with is that e.g.

Jakarta Concurrency says this

Under the Compatible Implementations for its latest release in Jakarta EE 9 while Jakarta Activation 2 says

Mail says

And JSON Processing 2.0 says

So those are at least 4 different patterns under the same Jakarta EE 9 platform release.

So while "Jakarta Concurrency CI 2.0.0" and "Eclipse Implementation of Jakarta Activation" (the latter without a version number though) both sound tolerable, there is no reason why those without an official implementation project name like "Hibernate", "Soteria", etc. should deviate so much.

 

Werner

 

Von: Wayne Beaton
Gesendet: Donnerstag, 4. Februar 2021 16:06
An: Jakarta specification committee
Betreff: Re: [jakarta.ee-spec.committee] Updating CompatibleImplementationbrands

 

> I can change the concurrency RI project name if needed if someone tells me what to do

 

Assuming that you mean the GitHub repository, ask webmaster for assistance.

 

Wayne

 

On Thu, Feb 4, 2021 at 5:05 AM Steve Millidge (Payara) <steve.millidge@xxxxxxxxxxx> wrote:

I can change the concurrency RI project name if needed if someone tells me what to do 😊

 

From: jakarta.ee-spec.committee <jakarta.ee-spec.committee-bounces@xxxxxxxxxxx> On Behalf Of Werner Keil
Sent: 03 February 2021 10:47
To: Jakarta specification committee <jakarta.ee-spec.committee@eclipse.org>
Subject: Re: [jakarta.ee-spec.committee] Updating Compatible Implementationbrands

 

I would not use "Eclipse JSON Processing 2.0.0." in one case while e.g. Jakarta Concurrency uses "Jakarta Concurrency CI 2.0.0.", see https://jakarta.ee/specifications/concurrency/2.0/, just add a "CI" there, too ;-)

 

Werner

 

Von: Jean-Louis Monteiro
Gesendet: Mittwoch, 3. Februar 2021 10:20
An: Jakarta specification committee
Betreff: Re: [jakarta.ee-spec.committee] Updating Compatible Implementationbrands

 

Yes, I agree.

There needs to be a clear difference in the naming. 

 

On Wed, Feb 3, 2021 at 12:01 AM David Blevins <dblevins@xxxxxxxxxxxxx> wrote:

Moving this to a separate thread so we don't overlook it.

> Unrelated comment, I noticed the compatible implementation listed for JSON P is wrong.  It says the compatible implementations name is "Jakarta JSON Processing 2.0.0."  That's not appropriate.  For 1.2 we used "Eclipse JSON Processing 1.1.5"
>
>  - https://jakarta.ee/specifications/jsonp/1.1/
>  - https://jakarta.ee/specifications/jsonp/2.0/
>
> This is part of the Advance Implementation Neutrality topic in our 2021 plan.  Thihup's implementation cannot be perceived as competing against "the official" Jakarta JSON Processing 2.0.0 implementation also called "Jakarta JSON Processing 2.0.0."
>
> No implementation should be allowed to use the spec branding like that, even if it is in at Eclipse, a former RI, or happens to be in the same repo as the spec.  The fact that the Eclipse implementation is in the same repo is something that needs to be fixed.  Until we fix it, we still need to use neutral branding like "Eclipse JSON Processing" or "Eclipse Mail."

Thoughts?


-David

_______________________________________________
jakarta.ee-spec.committee mailing list
jakarta.ee-spec.committee@eclipse.org
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec.committee

 

_______________________________________________
jakarta.ee-spec.committee mailing list
jakarta.ee-spec.committee@eclipse.org
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec.committee


 

--

Wayne Beaton

Director of Open Source Projects | Eclipse Foundation

 

_______________________________________________
jakarta.ee-spec.committee mailing list
jakarta.ee-spec.committee@eclipse.org
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec.committee

Back to the top