Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [starter-dev] Should the starter project require formal certification before allowing combinations of runtimes to be used?

I’m not a committer, but I think for now we should just stick with the certified runtimes and revisit later. Let’s focus on getting this out there, getting people using it, getting feedback, making improvements, etc.

___

Kito D. Mann | @kito99 | Java Champion | Google Developer Expert Alumni | LinkedIn
Expert consulting and training: Cloud architecture and modernization, Java/Jakarta EE, Web Components, Angular, Mobile Web
Virtua, Inc. | virtua.tech 

* Enterprise development, front and back. Listen to Stackd Podcast.
* Speak at conferences? Check out SpeakerTrax.

On April 4, 2023 at 1:59:21 PM, reza_rahman@xxxxxxxxx (reza_rahman@xxxxxxxxx) wrote:

I know. We are already pushing the boundaries of how dynamic the Archetype can be.

However, let’s first see how the discussion settles out. Hardly even all of our own committers have weighed in yet. We can then access how we could implement some of this.
 

From: starter-dev <starter-dev-bounces@xxxxxxxxxxx> on behalf of Scott Kurz <skurz@xxxxxxxxxx>
Sent: Tuesday, April 4, 2023 1:39 PM
To: starter developer discussions <starter-dev@xxxxxxxxxxx>
Subject: Re: [starter-dev] Should the starter project require formal certification before allowing combinations of runtimes to be used?
 

Any ideas how the checkbox on the web UI would translate to a mvn CLI  archetype:generate invocation?  

 

I was taking for granted there was a way but after a couple minutes thought I’m not sure how you’d do this.    I could imagine the generate script printing out a big warning “NOT YET CERTIFIED” but I don’t know how to hide or filter out the choices earlier on.

 

From: starter-dev <starter-dev-bounces@xxxxxxxxxxx> On Behalf Of Jeyvison Nascimento
Sent: Tuesday, April 4, 2023 12:00 PM
To: starter developer discussions <starter-dev@xxxxxxxxxxx>
Subject: [EXTERNAL] Re: [starter-dev] Should the starter project require formal certification before allowing combinations of runtimes to be used?

 

I'm note sure about this issue TBH but this solution Ondro proposed seems reasonable to me. Em ter. , 4 de abr. de 2023 16: 50, Ondro Mihályi <mihalyi@ omnifish. ee> escreveu: Maybe we could add support for a checkbox, which would also

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd

I'm note sure about this issue TBH but this solution Ondro proposed seems reasonable to me. 

 

Em ter., 4 de abr. de 2023 16:50, Ondro Mihályi <mihalyi@xxxxxxxxxxx> escreveu:

Maybe we could add support for a checkbox, which would also show non-certified runtimes. With this, non-certified runtimes wouldn't be visible by default, but if a user selects the checkbox to show all runtimes, they would become visible. I would still add an asterisk to those runtimes to make it clear which ones became visible by selecting the checkbox.

 

I think this is a good compromise between having only certified runtimes in the Starter and having any runtime added by the community. By default, nothing would be changed, unless users are searching for a specific runtime and select the checkbox to show all runtimes.

 

Any thoughts on this?

 

Ondro

 

On Tue, Apr 4, 2023 at 5:44 PM reza_rahman@xxxxxxxxx <reza_rahman@xxxxxxxxx> wrote:

I believe this is a worthy discussion, perhaps also ultimately for the Platform mailing list.

 

I think we should try very hard to stick to mirroring certification results. Otherwise we enter a potential minefield of fairness, avoiding user confusion, potential devaluation of certification, weakening compatibility, etc. This is of course especially acute as this is the official starter.

 

It would be good if others could weigh in on this. On Slack it was only myself, Scott, and Ondro that chimed in at all.

 


From: starter-dev <starter-dev-bounces@xxxxxxxxxxx> on behalf of Scott Kurz <skurz@xxxxxxxxxx>
Sent: Tuesday, April 4, 2023 11:09 AM
To: starter developer discussions <starter-dev@xxxxxxxxxxx>
Subject: [starter-dev] Should the starter project require formal certification before allowing combinations of runtimes to be used?

 

Let me raise the question from Slack: https://eclipsefoundationhq.slack.com/archives/C047MCS83FT/p1678788937498749 to the list here:

 

Should the Eclipse Starter for Jakarta EE project use formal compatibility/certification/etc. to guard use of the UI and underlying archetypes, for a given combination of runtime+profile+version?

 

An alternative might  be to allow someone working on a particular runtime to “vouch for” the usefulness of the function at a certain level if they work on the PR. 

 

E.g. with Open Liberty close to EE 10 compliance, I wouldn’t expect Reza or one of the starter project committers to go out of their way to enable this, but if I personally (as an Open Liberty committer) were to do the work to enable this then maybe my PR should be merged?

 

Some more thoughts:

 

Maybe there could be an asterisk (*) or warning/caveat about a runtime in such a not-yet-certified state?

 

If this is going to lead to debates about what should vs. shouldn’t be allowed though then perhaps it wouldn’t be worth it.   A nice thing about keying off formal certification is that we’ve already agreed to what counts as compatible.

 

I do see some potential for user confusion if uncertified runtimes are enabled via the starter. 

 

But the counterargument is to consider the case that we’re very far along on the way to certify against EE 10, we’ve got a lot of useful function and this convenient starter… let users take advantage of it.  They don’t care that we’re disputing three TCK test methods at this point.

And assuming the runtime is in some kind of beta / early release then presumably there’s going to be a suitable “warning” implicit in the non-final version of the particular runtime.

 

Anyway,  I could argue more with myself but let me send this out for discussion first.

 

Scott Kurz

 

 

 

 

 

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

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

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

Back to the top