Beside a BOM I assume there
also has to be a module-info at least from Jakarta EE 9
onwards, or would the minimal Java SE Version still remain
at Java 8 as it is for Jakarta EE 8?
Scott Stark wrote on 5/29/19 12:24 PM:
> Another question is how would we
envision a profile bom to be defined in an
> incremental vs Big Bang approach. The
incremental approach seems
> straightforward, there is a mix of
javax and jakarta based artifacts
> depending on what has been updated.
>
> The Big Bang bom leaves a question of
what should be in it. Consider a
> Jakarta EE 9 Big Bang release where
only the REST spec has been updated, but
> all apis now are under the jakarta.*
namespace. Greenfield development would
> only use jakarta.* based classes and
would work with a bom that only included
> those artifacts.
>
> If I have a Jakarta EE 8 app that is
updated to use the new REST apis, it
> would need to include both Jakarta EE
8 and Jakarta EE 9 boms to compile the
> app. Do we envision having a
compatibly bom such that there is a single bom a
> user could use to still build from
source against? The concern here is that
> they intended to update all REST api
usage to the Jakarta EE 9 apis, but
> missed some locations. If they have to
include both Jakarta EE 8 and Jakarta
> EE 9 boms, this would be masked. If
there was a Jakarta EE 9 compatibility
> bom, compiling against it would fail
on the locations that did not update
> from JAX-RS to the Jakarta EE 9 REST
apis.
That would only be an issue with the
incremental approach where the bom
would have the jakarta.rest.* APIs but not
the javax.ws.rs.* APIs, right?
If compatibility works by effectively
"aliasing" the javax names to the
jakarta names, an app, or even a class,
could mix and match javax names
and jakarta names and still work. (Whether
fine grained mixing is a good
idea is a separate issue. :-)) And yes,
it would need to depend on the
appropriate bom(s) or pom(s) to get access
to the APIs it needs.
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.
_______________________________________________
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
