How would that compatibility library differ from the API jar files
that already exist?
Scott Stark wrote on 5/29/19 2:04 PM:
What I am thinking I am starting to lean towards is a variation of
the incremental model where if a specification is updated, the
project does have to provide a compatibility library the allows
Jakarta EE 8 based components of the specification to compile as a
baseline for a compatibility step. Containers don’t necessarily
need to implement compatibility using that, but they could.
>
> Whether there's a "compatibility bom" and what it's
called would seem to
> depend on whether compatibility is a Jakarta EE
spec of some sort or whether
> it's left completely to products to provide. In
any event, there would
> continue to be the Jakarta EE 8 bom.
If we are
going to depend on Jakarta EE compatibility, then I
think it has to
be
defined here and not left up to each individual product.
Otherwise, we
have just
lost the compatibility argument.
_______________________________________________
jakarta.ee-spec.committee mailing list
jakarta.ee-spec.committee@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec.committee
|
