[DISCUSS] Release train for APIs and TomEE 8.x
Hi all, I'm planning to start some releases. First the javaee-api 8.0.x which essentially fixes some APIs that aren't part of EE 8 and which are messing up with Java Compiler after Java 11. Then TomEE 8.x with the new API and a fewx fixes and dependencies upgrade. And finally the jakartaee-api in a milestone version to start having more stable builds and see where we are. Any objections? -- Jean-Louis Monteiro http://twitter.com/jlouismonteiro http://www.tomitribe.com
Re: Removing non Java EE / Jakarta EE APIs from our javaee-api/jakartaee-api jars
I have done it and made sure the build was still green. Sent a new email to see if there are objections to release it and then TomEE 8.x -- Jean-Louis Monteiro http://twitter.com/jlouismonteiro http://www.tomitribe.com On Fri, May 20, 2022 at 7:35 AM Zowalla, Richard < richard.zowa...@hs-heilbronn.de> wrote: > 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 < > > > jlmonte...@tomitribe.com> 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 > > > > > > >
Re: [DISCUSS] Release train for APIs and TomEE 8.x
I am fine and have no objections. If you need help or some supporting hands, just give a ping. Gruß Richard Am Sonntag, dem 22.05.2022 um 20:36 +0200 schrieb Jean-Louis Monteiro: > Hi all, > > I'm planning to start some releases. > > First the javaee-api 8.0.x which essentially fixes some APIs that > aren't > part of EE 8 and which are messing up with Java Compiler after Java > 11. > > Then TomEE 8.x with the new API and a fewx fixes and dependencies > upgrade. > > And finally the jakartaee-api in a milestone version to start having > more > stable builds and see where we are. > > Any objections? > > -- > Jean-Louis Monteiro > http://twitter.com/jlouismonteiro > http://www.tomitribe.com smime.p7s Description: S/MIME cryptographic signature
Re: Removing non Java EE / Jakarta EE APIs from our javaee-api/jakartaee-api jars
The TomEE 8.x full build has some test failures due to missing deps, but that was to expect: https://ci-builds.apache.org/job/Tomee/job/tomee-8.x-build-full/72/ Mostly missing API classes (javax.cache) :) Am Sonntag, dem 22.05.2022 um 20:39 +0200 schrieb Jean-Louis Monteiro: > I have done it and made sure the build was still green. Sent a new > email to > see if there are objections to release it and then TomEE 8.x > -- > Jean-Louis Monteiro > http://twitter.com/jlouismonteiro > http://www.tomitribe.com > > > On Fri, May 20, 2022 at 7:35 AM Zowalla, Richard < > richard.zowa...@hs-heilbronn.de> wrote: > > > 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 < > > > > jlmonte...@tomitribe.com> 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
