I see no issues. We would need to add a clear list of APIs, which will be removed and document them in an Jira. We can then reference it in any potential release note, to indicate, that were was a change which might impact consumers.
Gruß Richard Am Dienstag, dem 17.05.2022 um 13:21 -0700 schrieb David Blevins: > > On May 17, 2022, at 8:17 AM, Jean-Louis Monteiro < > > [email protected]> wrote: > > > > Hi all, > > > > We do have an uber jar with all Java/Jakarta EE APIs. It makes it > > easier > > for a user to use the server and requires less dependencies in our > > modules. > > > > Though it's convenient, it looks like we are embedding too many > > APIs in it, > > and non EE APIs, for instance javax.xml.namespace. And since Java > > Modules > > it does generate compilation issues with Eclipse at least but also > > javac. > > > > Another option is to require the users to add a module-info.java > > with their > > explicit requirements so there is no conflict in the > > javax.xml.namespace > > package. > > > > Any issue to remove all non EE APIs from our Uber jar? > > No issues from me. Though it might be helpful if there was a to-be- > removed list we could take a look at as I know we keep removing > things from Jakarta with the idea that vendors can still implement > them and ship them, but they're just not officially part of the > platform anymore. > > For example the Embedded EJB Container is one of them that's been > removed. > > > > -David > > >
smime.p7s
Description: S/MIME cryptographic signature
