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

["Kevin Sutter" <sutter@xxxxxxxxxx>]

jakarta.ee-spec.committee-bounces@xxxxxxxxxxx
wrote on 05/29/2019 02:56:30 PM:

> From: Bill Shannon <bill.shannon@xxxxxxxxxx>
> To: Jakarta specification committee
<jakarta.ee-
> spec.committee@xxxxxxxxxxx>, Scott Stark <sstark@xxxxxxxxxx>
> Date: 05/29/2019 02:59 PM
> Subject: [EXTERNAL] Re: [jakarta.ee-spec.committee]
Incremental vs 
> Big Bang boms
> Sent by: jakarta.ee-spec.committee-bounces@xxxxxxxxxxx
> 
> 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.

I think we want this latter case
to fail.  If you forgot to update some of the
jax-rs usage, then your compile should
fail until you figure out how you want
to correct it.

> 
> 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?
> 

I trust this was just used as an
example since there is no requirement to change 
anything in the package name other
than javax.  If a component wishes to change
the package name (ie. javax.ws.rs.*
to jakarta.rest.*), then they are allowed
to.  But, I wouldn't recommend
it.  Keep the changes to a minimum.

> 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.

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://urldefense.proofpoint.com/v2/url?
> u=https-3A__www.eclipse.org_mailman_listinfo_jakarta.ee-2Dspec.committee&d=DwICAg&c=jf_iaSHvJObTbx-
> siA1ZOg&r=R9dtOS3afYnRUmu_zogmh0VnVYl2tse_V7QBUA9yr_4&m=WPHM1FV0xRHq3zxhuRQ88Sts-
> mobwkjbgE70umVOGYo&s=ToVHEIz1GiJei74xFzP3rgV3XCWiYn5VZ0MBvvTsQqQ&e=
>