Re: [jakarta.ee-spec.committee] Incremental vs Big Bang boms

[Scott Stark <sstark@xxxxxxxxxx>]

Let's focus on javax.ws.rs.Path moving to jakarta.ws.rs.Path, and I have updated updated a Jakarta EE 8 app to Jakarta EE 9 where the only change was in the REST spec. I expect that the Jakarta EE 9 bom will have:
- under incremental, the jakarta.ws.rs.* + all unmodified javax.* spect artifacts.
- under Big Bang, the  jakarta.ws.rs.* + all jakarta.* spec artifacts that simply had a package name change.

If I am using the incremental bom, I will only be able to compile my updated Jakarta EE 8 app if I have replaced all of the javax.ws.rs.Path usage.
If I am using the Big Bang bom, and I have only incrementally updated my app to what has functionally changed, then I also need to include the Jakarta EE 8 bom. Any location where I forgot to update javax.ws.rs.Path usage will be treated as Jakarta EE 8 and the binary compatibility layer will kick in. 

> On May 29, 2019, at 12:56 PM, Bill Shannon <bill.shannon@xxxxxxxxxx> wrote:
> 
>> 
>> 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.