You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomee.apache.org by Jean-Louis Monteiro <jl...@tomitribe.com> on 2022/05/17 15:17:25 UTC
Removing non Java EE / Jakarta EE APIs from our javaee-api/jakartaee-api jars
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?
--
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
Posted by "Zowalla, Richard" <ri...@hs-heilbronn.de>.
Yes. Examples + Arquillian Tests + TCKs
Most of the embedded TCKs + arquillian adaptors did not run due to a
build timeout after 12h (as CDI TCK never completed due to missing
javax.cache classes).
Am Montag, dem 23.05.2022 um 09:45 +0200 schrieb Jean-Louis Monteiro:
> Yes examples, but the main build itself is green.
> I'll get the examples fixed and start the javaee-api release in
> parallel.
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com
>
>
> On Mon, May 23, 2022 at 8:25 AM Zowalla, Richard <
> richard.zowalla@hs-heilbronn.de> wrote:
>
> > 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.zowalla@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 <
> > > > > > jlmonteiro@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: Removing non Java EE / Jakarta EE APIs from our javaee-api/jakartaee-api jars
Posted by Jean-Louis Monteiro <jl...@tomitribe.com>.
Yes examples, but the main build itself is green.
I'll get the examples fixed and start the javaee-api release in parallel.
--
Jean-Louis Monteiro
http://twitter.com/jlouismonteiro
http://www.tomitribe.com
On Mon, May 23, 2022 at 8:25 AM Zowalla, Richard <
richard.zowalla@hs-heilbronn.de> wrote:
> 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.zowalla@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 <
> > > > > jlmonteiro@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: Removing non Java EE / Jakarta EE APIs from our javaee-api/jakartaee-api jars
Posted by "Zowalla, Richard" <ri...@hs-heilbronn.de>.
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.zowalla@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 <
> > > > jlmonteiro@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: Removing non Java EE / Jakarta EE APIs from our javaee-api/jakartaee-api jars
Posted by Jean-Louis Monteiro <jl...@tomitribe.com>.
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.zowalla@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 <
> > > jlmonteiro@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: Removing non Java EE / Jakarta EE APIs from our javaee-api/jakartaee-api jars
Posted by "Zowalla, Richard" <ri...@hs-heilbronn.de>.
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 <
> > jlmonteiro@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: Removing non Java EE / Jakarta EE APIs from our javaee-api/jakartaee-api jars
Posted by David Blevins <db...@tomitribe.com>.
> On May 17, 2022, at 8:17 AM, Jean-Louis Monteiro <jl...@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: Removing non Java EE / Jakarta EE APIs from our javaee-api/jakartaee-api jars
Posted by Jonathan Gallimore <jo...@gmail.com>.
I'm ok with it. Thanks Jean-Louis.
Jon
On Tue, May 17, 2022 at 4:17 PM Jean-Louis Monteiro <
jlmonteiro@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?
>
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com
>