| Re: [jakarta.ee-spec.committee] Incremental vs Big Bang boms |
|
https://www.payara.fish/support/support-lifecycle/ This is why people buy support rather than use latest community releases.
Steve From: jakarta.ee-spec.committee-bounces@xxxxxxxxxxx <jakarta.ee-spec.committee-bounces@xxxxxxxxxxx>
On Behalf Of Werner Keil Good Points. @Steve, how Long does for example Payara provide support and significant updates of both Payara 4 and 5 side by side? Werner Sent from
Mail for Windows 10 From: Kazumura, Kenji Steve, I 'm not sure other country, but it likely happens in Japan. (1) A vendor provides a Jakarta EE 9 product which run with Java SE 13, and a customer want to use Java SE 13 features (but not want to use Jakarta EE 9 new features). In this case, this customer must use Jakarta EE 9 product, unless we provide Jakarta EE 8 product which run with Java SE 13. (2) The customers, who wants a long term support, usually
select the newer version product. For example, the date of EOL for Jakarta EE 9 product is later than the one for Jakarta EE 8. They select Jakarta EE 9 product because they want to use it as long as possible. -Kenji Kazumura > -----Original Message----- > From:
jakarta.ee-spec.committee-bounces@xxxxxxxxxxx > [mailto:jakarta.ee-spec.committee-bounces@xxxxxxxxxxx] On Behalf Of Steve Millidge (Payara) > Sent: Thursday, May 30, 2019 6:48 PM > To: Jakarta specification committee <jakarta.ee-spec.committee@xxxxxxxxxxx> > Subject: Re: [jakarta.ee-spec.committee] Incremental vs Big Bang boms > > Hi Kenji, > > I may have missed something subtle in your email but if the customer is not using any Jakarta EE 9 features then > don't they just have a Jakarta EE 8 app and therefore can't they just use the Jakarta EE 8 bom? > > Steve > > -----Original Message----- > From:
jakarta.ee-spec.committee-bounces@xxxxxxxxxxx <jakarta.ee-spec.committee-bounces@xxxxxxxxxxx> On > Behalf Of Kazumura, Kenji > Sent: 30 May 2019 08:07 > To: Jakarta specification committee <jakarta.ee-spec.committee@xxxxxxxxxxx> > Subject: Re: [jakarta.ee-spec.committee] Incremental vs Big Bang boms > > Assume that you have an existing Jakarta EE 8 app, and you want to change just your own business logic, but you > don't want to use any new features in Jakarta EE 9. > You don't need to change the package names in your source code when using incremental bom, while you need to > change all the package names in your source when using big bang bom. > > If we choose the big bang approach, this type of customers do not have motivation to use Jakarta EE 9. > My concern is, if a vendor has a lot of this type of existing customers, this vendor also does not have motivation > to provide Jakarta EE 9 products. > > -Kenji Kazumura > > > > -----Original Message----- > > From:
jakarta.ee-spec.committee-bounces@xxxxxxxxxxx > > [mailto:jakarta.ee-spec.committee-bounces@xxxxxxxxxxx] On Behalf Of > > Bill Shannon > > Sent: Thursday, May 30, 2019 6:10 AM > > To: Scott Stark <sstark@xxxxxxxxxx> > > Cc: Jakarta specification committee > > <jakarta.ee-spec.committee@xxxxxxxxxxx> > > Subject: Re: [jakarta.ee-spec.committee] Incremental vs Big Bang boms > > > > If you have an existing app that's using the Jakarta EE 8 bom and you > > update part of that app to use the new features in Jakarta EE 9, e.g., > > the jakarta.ws.rs.Path class, you'll need to add something to your app > > configuration to get access to the new API, either by adding the > > entire Jakarta EE 9 bom or by adding the adding the new Jakarta > > RESTful Web Services API pom. > > > > That's the same with Incremental or Big Bang. > > > > > > Scott Stark wrote on 5/29/19 1:43 PM: > > > 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. > > > > > _______________________________________________ > > 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 > > > _______________________________________________ > 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 > _______________________________________________ > 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 _______________________________________________ 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 |