Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakarta.ee-spec.committee] Incremental vs Big Bang boms

That would be an issue for the "compatibility spec".

If compatibility is handled by aliasing the old names to the new names, the module names might be just the new module names (assuming the new specs define module names).  I don't think there's any need to define "old" module names for the "old" APIs.

Werner Keil wrote on 5/29/19 1:34 PM:

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?

 

 

From: Bill Shannon
Sent: Wednesday, May 29, 2019 21:59
To: Jakarta specification committee; Scott Stark
Subject: Re: [jakarta.ee-spec.committee] Incremental vs Big Bang boms

 

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

 


_______________________________________________
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


Back to the top