+1
___
Expert consulting and training: Cloud architecture and modernization, Java/Jakarta EE, Web Components, Angular, Mobile Web
On April 22, 2023 at 12:04:59 PM, Reza Rahman (reza_rahman@xxxxxxxxx) wrote:
This issue was surfaced to the Jakarta EE steering committee for
advice. The clear consensus is to stick closely to certification
results. I believe we should consider this matter resolved and
move forward.
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.
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
|
This Message Is
From an External Sender
|
|
This message came
from outside your organization.
|
|
|
I'm note sure about this issue TBH
but this solution Ondro proposed seems reasonable to
me.
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.
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.
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
|
