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/07/04 08:49:36 UTC
Re: TomEE 9.x - from javax to jakarta namespace
Hi,
Bumping this thread up
Not yet at the point where I'm clear on what path to use regarding the API,
but it's been a while so I wanted to provide some status.
You may have noticed the VOTE thread going on regarding TomEE 9.0.0-M2.
This is the first real milestone for TomEE with the actual source code
migrated to jakarta. It means that full packaged distributions (WebProfile,
MicroProfile, Plume and Plus ZIP/TAR.GZ) should be mostly working. But the
application composer, the JUnit support, even Arquillian are now fully
migrated. We had to do a lot of shading/relocation of certain libraries on
our side because libraries were not yet ready.
We've worked very hard but we are finally looking good. We still have a few
failures on our build to solve, but the platform TCK + CDI + BVal are
looking good with less than 50 failures of 35K tests.
Please remember this is a milestone and we are all still working on it. Any
feedback is appreciated and will help.
We started also upgrading our MicroProfile support to the latest one. So
far Config, Health and Metrics are fully migrated and passing the TCK. We
are actively working on MicroProfile JWT. And we'll be proceeding with the
others when possible.
If you haven't done it yet, please try it and feel free to vote.
--
Jean-Louis Monteiro
http://twitter.com/jlouismonteiro
http://www.tomitribe.com
On Thu, May 26, 2022 at 1:28 PM Jean-Louis Monteiro <
jlmonteiro@tomitribe.com> wrote:
> Hi,
>
> quick feedback before getting into more details
>
> A/ or this alternative
> Geronimo Specs were not available in the Jakarta namespace. We are
> starting to move some of them like Activation and Mail. Other than that, we
> mainly have Eclipse produced APIs for Jakarta.
> I'm not sure if we want to migrate our Geronimo Specs jars or use the
> stock Jakarta APIs. Important note, if we do, we may not need the
> jakartaee-api because there is already a Uber jar for Jakarta within the
> different profiles. Should we get our user to use it as provided. And on
> our side, should we create just a bom in our project and get the job done?
>
> Some APIs are also more or less implementations and vice versa. This is
> the case for mail, faces, and some more as you mentioned. I'm fine
> including Mail provider + Geronimo Mail spec in the jakartaee-api jar but
> mind that in the past some users wanted to use Sun implementation and it
> will be harder
>
> D/ what about inconsistencies like ...
> Some implementations can be switched, for example Faces. Which is also a
> mess because API and IMPL are linked together. I had previously the Faces
> API but of course you need the implementation as well, same as for mail.
> But Plume uses Mojorra. So we are in the situation where we need to pick
> one or the other.
>
> B/ or this alternative ...
> Tomcat classifier because we don't want to cheap with APIs already
> provided in Tomcat with the risk of not being fully aligned. So we use
> Tomcat APIs. Should we go the way around and remove Tomcat APIs from the
> final distribution and get rid of the Tomcat classifier?
>
> Note sure if my reply is clear, hopefully it helps.
>
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com
>
>
> On Thu, May 26, 2022 at 3:23 AM David Blevins <da...@gmail.com>
> wrote:
>
>> Thanks so much for this. I even started creating one myself early this
>> morning, ... then the rest of the day happened LOL
>>
>> > On May 25, 2022, at 1:56 PM, Jean-Louis Monteiro <
>> jlmonteiro@tomitribe.com> wrote:
>> >
>> > Here it is
>> >
>> https://gist.github.com/jeanouii/9bb6c14bdde227e2fed83fd73db3a646/revisions
>>
>> Looks like we've yanked out Faces, JSTL, Mail, etc. I suspect we're
>> trying to hit the line of not including APIs that are implementations. The
>> real trick is even HttpServlet is completely dependent on the servlet
>> container in the same way Faces, Mail, JSTL, etc are dependent on their
>> implementations. I'm not too sure if Activation is also considered an
>> implementation as well -- I'm not sure off-hand if there is a separate
>> implementation jar.
>>
>> I know we didn't include mail in our javaee-api jar, so excluding is
>> following that logic. I also know we have the
>> jakartaee-api-9.1-M2-SNAPSHOT-tomcat.jar, which cuts out everything very
>> close to the way we've now done it in jakartaee-api-9.1-M2-SNAPSHOT.jar
>>
>> How do we want to handle this?
>>
>> Seems our options are:
>>
>> A. Leave jakartaee-api-X.jar and jakartaee-api-X-tomcat.jar nearly
>> identical in missing many specs. There is no uber jar people can compile
>> against that has most everything. People would need to discover which
>> specs are missing and pull them in individually.
>>
>> B. Eliminate having two jars, there is now just
>> jakartaee-api-X-tomcat.jar (which we call jakartaee-api-X.jar). There is
>> no uber jar people can compile against that has most everything. People
>> would need to discover which specs are missing and pull them in
>> individually.
>>
>> C. Do what we did with javaee-api.jar and leave mail out while including
>> other impls. There is something close to an uber, but still not quite as
>> identical to the jakartaee-api jar produced at Eclipse using the Eclipse
>> impls.
>>
>> D. Reverse our stance on the mail thing. There would be jakartaee-api
>> that contained everything including mail and it would be identical to the
>> jakartaee-api jar produced at Eclipse using the Eclipse impls.
>>
>> Not sure where I sit on this spectrum yet, throwing it out so we all can
>> think in parallel.
>>
>> Is it at all possible to get a similar diff for the "-tomcat" jar?
>>
>>
>> -David
>>
>>
>
>
Re: TomEE 9.x - from javax to jakarta namespace
Posted by Swell <so...@gmail.com>.
Hi, thanks Jean-Louis,
I've tried replacing "geronimo specs" dependencies with "jakartaee apis"
dependencies,
while this does allow to easily exclude implementations jars, it could also
have an impact on the OSGI system used by TomEE to locate services.
(it seems its only used to locate the EJB container, am i right ?)
i would like to be able to replace the geronimo osgi locator by a custom
one for TomEE, but i currently can't on my own.
though, i could provide a gist file for the POM dependencies changes
(possibly no geronimo deps in the end).
if someone else is willing to jump on this adventure with me they're
welcome.
---
Swell.
side note, i cant build the "tomee-jakarta" project i'm working on my
windows, so i'll try on a mac later.
cant submit a PR atm but still trying things.
On Mon, 11 Jul 2022 at 11:50, Jean-Louis Monteiro <jl...@tomitribe.com>
wrote:
> Hi Swell;
>
> You answer and thoughts are more than welcome.
>
> For the moment we use the same approach, exclude APIs where the IMPL is
> packaged in (Mail and Faces at least).
> Yes Jakarta also provides an Uber jar, and regardless of the fact it is
> outdated or not, it has the same issue. Using the Uber jar automatically
> brings use Sun Mail implementation and Faces Mojorra implementation.
>
> i believe there could be :
> >
> > - one up to date bom for all api only.
> >
> Does not seem to solve the issue as the dependency for the API would also
> bring the implementation because it's one jar only and one dependency only.
>
>
> > - one uber apis jar per TomEE flavor.
> >
> Yes I was thinking about this one as well.
>
>
> > - separated original implementation jars from providers.
> >
> We would need to dig into the specifics to see if that is possible and how.
>
>
> Yes feel free to submit a PR and ping us on the mailing list to get
> feedback and reviews.
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com
>
>
> On Wed, Jul 6, 2022 at 11:27 AM Swell <so...@gmail.com> wrote:
>
> > Hi, regarding the APIs
> >
> > i hope that my answer is not off-topic, what I believe is someone using
> our
> > uber api jar would want the apis without impl, even for mail and faces.
> > if i were to use it i would want implementations separated on their own
> > official jar, but not fused together.
> >
> > as a note there exist a bom for jakarta ee but its outdated
> >
> >
> https://mvnrepository.com/artifact/jakarta.platform/jakarta.jakartaee-bom/9.1.0
> > the official one provided lacks the minor fixes (e.g points to EJB 4.0.0
> > instead of 4.0.1, to cite only one of the problems)
> >
> > i believe there could be :
> >
> > - one up to date bom for all api only.
> > - one uber apis jar per TomEE flavor.
> > - separated original implementation jars from providers.
> >
> > we provide an up-to-date jakarta ee javadoc to cover the lack (which i
> > updated the api versions), in the same idea
> > would it be ok for TomEE project to provide both such a BOM and uber apis
> > jar ? (which i could update side by side with javadoc)
> >
> > --
> > Swell
> >
> > On Mon, 4 Jul 2022 at 10:50, Jean-Louis Monteiro <
> jlmonteiro@tomitribe.com
> > >
> > wrote:
> >
> > > Hi,
> > >
> > > Bumping this thread up
> > > Not yet at the point where I'm clear on what path to use regarding the
> > API,
> > > but it's been a while so I wanted to provide some status.
> > >
> > > You may have noticed the VOTE thread going on regarding TomEE 9.0.0-M2.
> > > This is the first real milestone for TomEE with the actual source code
> > > migrated to jakarta. It means that full packaged distributions
> > (WebProfile,
> > > MicroProfile, Plume and Plus ZIP/TAR.GZ) should be mostly working. But
> > the
> > > application composer, the JUnit support, even Arquillian are now
> fullyHi,
> > > migrated. We had to do a lot of shading/relocation of certain libraries
> > on
> > > our side because libraries were not yet ready.
> > >
> > > We've worked very hard but we are finally looking good. We still have a
> > few
> > > failures on our build to solve, but the platform TCK + CDI + BVal are
> > > looking good with less than 50 failures of 35K tests.
> > >
> > > Please remember this is a milestone and we are all still working on it.
> > Any
> > > feedback is appreciated and will help.
> > >
> > > We started also upgrading our MicroProfile support to the latest one.
> So
> > > far Config, Health and Metrics are fully migrated and passing the TCK.
> We
> > > are actively working on MicroProfile JWT. And we'll be proceeding with
> > the
> > > others when possible.
> > >
> > > If you haven't done it yet, please try it and feel free to vote.
> > >
> > > --
> > > Jean-Louis Monteiro
> > > http://twitter.com/jlouismonteiro
> > > http://www.tomitribe.com
> > >
> > >
> > > On Thu, May 26, 2022 at 1:28 PM Jean-Louis Monteiro <
> > > jlmonteiro@tomitribe.com> wrote:
> > >
> > > > Hi,
> > > >
> > > > quick feedback before getting into more details
> > > >
> > > > A/ or this alternative
> > > > Geronimo Specs were not available in the Jakarta namespace. We are
> > > > starting to move some of them like Activation and Mail. Other than
> > that,
> > > we
> > > > mainly have Eclipse produced APIs for Jakarta.
> > > > I'm not sure if we want to migrate our Geronimo Specs jars or use the
> > > > stock Jakarta APIs. Important note, if we do, we may not need the
> > > > jakartaee-api because there is already a Uber jar for Jakarta within
> > the
> > > > different profiles. Should we get our user to use it as provided. And
> > on
> > > > our side, should we create just a bom in our project and get the job
> > > done?
> > > >
> > > > Some APIs are also more or less implementations and vice versa. This
> is
> > > > the case for mail, faces, and some more as you mentioned. I'm fine
> > > > including Mail provider + Geronimo Mail spec in the jakartaee-api jar
> > but
> > > > mind that in the past some users wanted to use Sun implementation and
> > it
> > > > will be harder
> > > >
> > > > D/ what about inconsistencies like ...
> > > > Some implementations can be switched, for example Faces. Which is
> also
> > a
> > > > mess because API and IMPL are linked together. I had previously the
> > Faces
> > > > API but of course you need the implementation as well, same as for
> > mail.
> > > > But Plume uses Mojorra. So we are in the situation where we need to
> > pick
> > > > one or the other.
> > > >
> > > > B/ or this alternative ...
> > > > Tomcat classifier because we don't want to cheap with APIs already
> > > > provided in Tomcat with the risk of not being fully aligned. So we
> use
> > > > Tomcat APIs. Should we go the way around and remove Tomcat APIs from
> > the
> > > > final distribution and get rid of the Tomcat classifier?
> > > >
> > > > Note sure if my reply is clear, hopefully it helps.
> > > >
> > > > --
> > > > Jean-Louis Monteiro
> > > > http://twitter.com/jlouismonteiro
> > > > http://www.tomitribe.com
> > > >
> > > >
> > > > On Thu, May 26, 2022 at 3:23 AM David Blevins <
> david.blevins@gmail.com
> > >
> > > > wrote:
> > > >
> > > >> Thanks so much for this. I even started creating one myself early
> > this
> > > >> morning, ... then the rest of the day happened LOL
> > > >>
> > > >> > On May 25, 2022, at 1:56 PM, Jean-Louis Monteiro <
> > > >> jlmonteiro@tomitribe.com> wrote:
> > > >> >
> > > >> > Here it is
> > > >> >
> > > >>
> > >
> >
> https://gist.github.com/jeanouii/9bb6c14bdde227e2fed83fd73db3a646/revisions
> > > >>
> > > >> Looks like we've yanked out Faces, JSTL, Mail, etc. I suspect we're
> > > >> trying to hit the line of not including APIs that are
> implementations.
> > > The
> > > >> real trick is even HttpServlet is completely dependent on the
> servlet
> > > >> container in the same way Faces, Mail, JSTL, etc are dependent on
> > their
> > > >> implementations. I'm not too sure if Activation is also considered
> an
> > > >> implementation as well -- I'm not sure off-hand if there is a
> separate
> > > >> implementation jar.
> > > >>
> > > >> I know we didn't include mail in our javaee-api jar, so excluding is
> > > >> following that logic. I also know we have the
> > > >> jakartaee-api-9.1-M2-SNAPSHOT-tomcat.jar, which cuts out everything
> > very
> > > >> close to the way we've now done it in
> > jakartaee-api-9.1-M2-SNAPSHOT.jar
> > > >>
> > > >> How do we want to handle this?
> > > >>
> > > >> Seems our options are:
> > > >>
> > > >> A. Leave jakartaee-api-X.jar and jakartaee-api-X-tomcat.jar nearly
> > > >> identical in missing many specs. There is no uber jar people can
> > > compile
> > > >> against that has most everything. People would need to discover
> which
> > > >> specs are missing and pull them in individually.
> > > >>
> > > >> B. Eliminate having two jars, there is now just
> > > >> jakartaee-api-X-tomcat.jar (which we call jakartaee-api-X.jar).
> There
> > > is
> > > >> no uber jar people can compile against that has most everything.
> > People
> > > >> would need to discover which specs are missing and pull them in
> > > >> individually.
> > > >>
> > > >> C. Do what we did with javaee-api.jar and leave mail out while
> > > including
> > > >> other impls. There is something close to an uber, but still not
> quite
> > > as
> > > >> identical to the jakartaee-api jar produced at Eclipse using the
> > Eclipse
> > > >> impls.
> > > >>
> > > >> D. Reverse our stance on the mail thing. There would be
> > jakartaee-api
> > > >> that contained everything including mail and it would be identical
> to
> > > the
> > > >> jakartaee-api jar produced at Eclipse using the Eclipse impls.
> > > >>
> > > >> Not sure where I sit on this spectrum yet, throwing it out so we all
> > can
> > > >> think in parallel.
> > > >>
> > > >> Is it at all possible to get a similar diff for the "-tomcat" jar?
> > > >>
> > > >>
> > > >> -David
> > > >>
> > > >>
> > > >
> > > >
> > >
> >
>
Re: TomEE 9.x - from javax to jakarta namespace
Posted by Jean-Louis Monteiro <jl...@tomitribe.com>.
Hi Swell;
You answer and thoughts are more than welcome.
For the moment we use the same approach, exclude APIs where the IMPL is
packaged in (Mail and Faces at least).
Yes Jakarta also provides an Uber jar, and regardless of the fact it is
outdated or not, it has the same issue. Using the Uber jar automatically
brings use Sun Mail implementation and Faces Mojorra implementation.
i believe there could be :
>
> - one up to date bom for all api only.
>
Does not seem to solve the issue as the dependency for the API would also
bring the implementation because it's one jar only and one dependency only.
> - one uber apis jar per TomEE flavor.
>
Yes I was thinking about this one as well.
> - separated original implementation jars from providers.
>
We would need to dig into the specifics to see if that is possible and how.
Yes feel free to submit a PR and ping us on the mailing list to get
feedback and reviews.
--
Jean-Louis Monteiro
http://twitter.com/jlouismonteiro
http://www.tomitribe.com
On Wed, Jul 6, 2022 at 11:27 AM Swell <so...@gmail.com> wrote:
> Hi, regarding the APIs
>
> i hope that my answer is not off-topic, what I believe is someone using our
> uber api jar would want the apis without impl, even for mail and faces.
> if i were to use it i would want implementations separated on their own
> official jar, but not fused together.
>
> as a note there exist a bom for jakarta ee but its outdated
>
> https://mvnrepository.com/artifact/jakarta.platform/jakarta.jakartaee-bom/9.1.0
> the official one provided lacks the minor fixes (e.g points to EJB 4.0.0
> instead of 4.0.1, to cite only one of the problems)
>
> i believe there could be :
>
> - one up to date bom for all api only.
> - one uber apis jar per TomEE flavor.
> - separated original implementation jars from providers.
>
> we provide an up-to-date jakarta ee javadoc to cover the lack (which i
> updated the api versions), in the same idea
> would it be ok for TomEE project to provide both such a BOM and uber apis
> jar ? (which i could update side by side with javadoc)
>
> --
> Swell
>
> On Mon, 4 Jul 2022 at 10:50, Jean-Louis Monteiro <jlmonteiro@tomitribe.com
> >
> wrote:
>
> > Hi,
> >
> > Bumping this thread up
> > Not yet at the point where I'm clear on what path to use regarding the
> API,
> > but it's been a while so I wanted to provide some status.
> >
> > You may have noticed the VOTE thread going on regarding TomEE 9.0.0-M2.
> > This is the first real milestone for TomEE with the actual source code
> > migrated to jakarta. It means that full packaged distributions
> (WebProfile,
> > MicroProfile, Plume and Plus ZIP/TAR.GZ) should be mostly working. But
> the
> > application composer, the JUnit support, even Arquillian are now fullyHi,
> > migrated. We had to do a lot of shading/relocation of certain libraries
> on
> > our side because libraries were not yet ready.
> >
> > We've worked very hard but we are finally looking good. We still have a
> few
> > failures on our build to solve, but the platform TCK + CDI + BVal are
> > looking good with less than 50 failures of 35K tests.
> >
> > Please remember this is a milestone and we are all still working on it.
> Any
> > feedback is appreciated and will help.
> >
> > We started also upgrading our MicroProfile support to the latest one. So
> > far Config, Health and Metrics are fully migrated and passing the TCK. We
> > are actively working on MicroProfile JWT. And we'll be proceeding with
> the
> > others when possible.
> >
> > If you haven't done it yet, please try it and feel free to vote.
> >
> > --
> > Jean-Louis Monteiro
> > http://twitter.com/jlouismonteiro
> > http://www.tomitribe.com
> >
> >
> > On Thu, May 26, 2022 at 1:28 PM Jean-Louis Monteiro <
> > jlmonteiro@tomitribe.com> wrote:
> >
> > > Hi,
> > >
> > > quick feedback before getting into more details
> > >
> > > A/ or this alternative
> > > Geronimo Specs were not available in the Jakarta namespace. We are
> > > starting to move some of them like Activation and Mail. Other than
> that,
> > we
> > > mainly have Eclipse produced APIs for Jakarta.
> > > I'm not sure if we want to migrate our Geronimo Specs jars or use the
> > > stock Jakarta APIs. Important note, if we do, we may not need the
> > > jakartaee-api because there is already a Uber jar for Jakarta within
> the
> > > different profiles. Should we get our user to use it as provided. And
> on
> > > our side, should we create just a bom in our project and get the job
> > done?
> > >
> > > Some APIs are also more or less implementations and vice versa. This is
> > > the case for mail, faces, and some more as you mentioned. I'm fine
> > > including Mail provider + Geronimo Mail spec in the jakartaee-api jar
> but
> > > mind that in the past some users wanted to use Sun implementation and
> it
> > > will be harder
> > >
> > > D/ what about inconsistencies like ...
> > > Some implementations can be switched, for example Faces. Which is also
> a
> > > mess because API and IMPL are linked together. I had previously the
> Faces
> > > API but of course you need the implementation as well, same as for
> mail.
> > > But Plume uses Mojorra. So we are in the situation where we need to
> pick
> > > one or the other.
> > >
> > > B/ or this alternative ...
> > > Tomcat classifier because we don't want to cheap with APIs already
> > > provided in Tomcat with the risk of not being fully aligned. So we use
> > > Tomcat APIs. Should we go the way around and remove Tomcat APIs from
> the
> > > final distribution and get rid of the Tomcat classifier?
> > >
> > > Note sure if my reply is clear, hopefully it helps.
> > >
> > > --
> > > Jean-Louis Monteiro
> > > http://twitter.com/jlouismonteiro
> > > http://www.tomitribe.com
> > >
> > >
> > > On Thu, May 26, 2022 at 3:23 AM David Blevins <david.blevins@gmail.com
> >
> > > wrote:
> > >
> > >> Thanks so much for this. I even started creating one myself early
> this
> > >> morning, ... then the rest of the day happened LOL
> > >>
> > >> > On May 25, 2022, at 1:56 PM, Jean-Louis Monteiro <
> > >> jlmonteiro@tomitribe.com> wrote:
> > >> >
> > >> > Here it is
> > >> >
> > >>
> >
> https://gist.github.com/jeanouii/9bb6c14bdde227e2fed83fd73db3a646/revisions
> > >>
> > >> Looks like we've yanked out Faces, JSTL, Mail, etc. I suspect we're
> > >> trying to hit the line of not including APIs that are implementations.
> > The
> > >> real trick is even HttpServlet is completely dependent on the servlet
> > >> container in the same way Faces, Mail, JSTL, etc are dependent on
> their
> > >> implementations. I'm not too sure if Activation is also considered an
> > >> implementation as well -- I'm not sure off-hand if there is a separate
> > >> implementation jar.
> > >>
> > >> I know we didn't include mail in our javaee-api jar, so excluding is
> > >> following that logic. I also know we have the
> > >> jakartaee-api-9.1-M2-SNAPSHOT-tomcat.jar, which cuts out everything
> very
> > >> close to the way we've now done it in
> jakartaee-api-9.1-M2-SNAPSHOT.jar
> > >>
> > >> How do we want to handle this?
> > >>
> > >> Seems our options are:
> > >>
> > >> A. Leave jakartaee-api-X.jar and jakartaee-api-X-tomcat.jar nearly
> > >> identical in missing many specs. There is no uber jar people can
> > compile
> > >> against that has most everything. People would need to discover which
> > >> specs are missing and pull them in individually.
> > >>
> > >> B. Eliminate having two jars, there is now just
> > >> jakartaee-api-X-tomcat.jar (which we call jakartaee-api-X.jar). There
> > is
> > >> no uber jar people can compile against that has most everything.
> People
> > >> would need to discover which specs are missing and pull them in
> > >> individually.
> > >>
> > >> C. Do what we did with javaee-api.jar and leave mail out while
> > including
> > >> other impls. There is something close to an uber, but still not quite
> > as
> > >> identical to the jakartaee-api jar produced at Eclipse using the
> Eclipse
> > >> impls.
> > >>
> > >> D. Reverse our stance on the mail thing. There would be
> jakartaee-api
> > >> that contained everything including mail and it would be identical to
> > the
> > >> jakartaee-api jar produced at Eclipse using the Eclipse impls.
> > >>
> > >> Not sure where I sit on this spectrum yet, throwing it out so we all
> can
> > >> think in parallel.
> > >>
> > >> Is it at all possible to get a similar diff for the "-tomcat" jar?
> > >>
> > >>
> > >> -David
> > >>
> > >>
> > >
> > >
> >
>
Re: TomEE 9.x - from javax to jakarta namespace
Posted by Swell <so...@gmail.com>.
Hi, regarding the APIs
i hope that my answer is not off-topic, what I believe is someone using our
uber api jar would want the apis without impl, even for mail and faces.
if i were to use it i would want implementations separated on their own
official jar, but not fused together.
as a note there exist a bom for jakarta ee but its outdated
https://mvnrepository.com/artifact/jakarta.platform/jakarta.jakartaee-bom/9.1.0
the official one provided lacks the minor fixes (e.g points to EJB 4.0.0
instead of 4.0.1, to cite only one of the problems)
i believe there could be :
- one up to date bom for all api only.
- one uber apis jar per TomEE flavor.
- separated original implementation jars from providers.
we provide an up-to-date jakarta ee javadoc to cover the lack (which i
updated the api versions), in the same idea
would it be ok for TomEE project to provide both such a BOM and uber apis
jar ? (which i could update side by side with javadoc)
--
Swell
On Mon, 4 Jul 2022 at 10:50, Jean-Louis Monteiro <jl...@tomitribe.com>
wrote:
> Hi,
>
> Bumping this thread up
> Not yet at the point where I'm clear on what path to use regarding the API,
> but it's been a while so I wanted to provide some status.
>
> You may have noticed the VOTE thread going on regarding TomEE 9.0.0-M2.
> This is the first real milestone for TomEE with the actual source code
> migrated to jakarta. It means that full packaged distributions (WebProfile,
> MicroProfile, Plume and Plus ZIP/TAR.GZ) should be mostly working. But the
> application composer, the JUnit support, even Arquillian are now fullyHi,
> migrated. We had to do a lot of shading/relocation of certain libraries on
> our side because libraries were not yet ready.
>
> We've worked very hard but we are finally looking good. We still have a few
> failures on our build to solve, but the platform TCK + CDI + BVal are
> looking good with less than 50 failures of 35K tests.
>
> Please remember this is a milestone and we are all still working on it. Any
> feedback is appreciated and will help.
>
> We started also upgrading our MicroProfile support to the latest one. So
> far Config, Health and Metrics are fully migrated and passing the TCK. We
> are actively working on MicroProfile JWT. And we'll be proceeding with the
> others when possible.
>
> If you haven't done it yet, please try it and feel free to vote.
>
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com
>
>
> On Thu, May 26, 2022 at 1:28 PM Jean-Louis Monteiro <
> jlmonteiro@tomitribe.com> wrote:
>
> > Hi,
> >
> > quick feedback before getting into more details
> >
> > A/ or this alternative
> > Geronimo Specs were not available in the Jakarta namespace. We are
> > starting to move some of them like Activation and Mail. Other than that,
> we
> > mainly have Eclipse produced APIs for Jakarta.
> > I'm not sure if we want to migrate our Geronimo Specs jars or use the
> > stock Jakarta APIs. Important note, if we do, we may not need the
> > jakartaee-api because there is already a Uber jar for Jakarta within the
> > different profiles. Should we get our user to use it as provided. And on
> > our side, should we create just a bom in our project and get the job
> done?
> >
> > Some APIs are also more or less implementations and vice versa. This is
> > the case for mail, faces, and some more as you mentioned. I'm fine
> > including Mail provider + Geronimo Mail spec in the jakartaee-api jar but
> > mind that in the past some users wanted to use Sun implementation and it
> > will be harder
> >
> > D/ what about inconsistencies like ...
> > Some implementations can be switched, for example Faces. Which is also a
> > mess because API and IMPL are linked together. I had previously the Faces
> > API but of course you need the implementation as well, same as for mail.
> > But Plume uses Mojorra. So we are in the situation where we need to pick
> > one or the other.
> >
> > B/ or this alternative ...
> > Tomcat classifier because we don't want to cheap with APIs already
> > provided in Tomcat with the risk of not being fully aligned. So we use
> > Tomcat APIs. Should we go the way around and remove Tomcat APIs from the
> > final distribution and get rid of the Tomcat classifier?
> >
> > Note sure if my reply is clear, hopefully it helps.
> >
> > --
> > Jean-Louis Monteiro
> > http://twitter.com/jlouismonteiro
> > http://www.tomitribe.com
> >
> >
> > On Thu, May 26, 2022 at 3:23 AM David Blevins <da...@gmail.com>
> > wrote:
> >
> >> Thanks so much for this. I even started creating one myself early this
> >> morning, ... then the rest of the day happened LOL
> >>
> >> > On May 25, 2022, at 1:56 PM, Jean-Louis Monteiro <
> >> jlmonteiro@tomitribe.com> wrote:
> >> >
> >> > Here it is
> >> >
> >>
> https://gist.github.com/jeanouii/9bb6c14bdde227e2fed83fd73db3a646/revisions
> >>
> >> Looks like we've yanked out Faces, JSTL, Mail, etc. I suspect we're
> >> trying to hit the line of not including APIs that are implementations.
> The
> >> real trick is even HttpServlet is completely dependent on the servlet
> >> container in the same way Faces, Mail, JSTL, etc are dependent on their
> >> implementations. I'm not too sure if Activation is also considered an
> >> implementation as well -- I'm not sure off-hand if there is a separate
> >> implementation jar.
> >>
> >> I know we didn't include mail in our javaee-api jar, so excluding is
> >> following that logic. I also know we have the
> >> jakartaee-api-9.1-M2-SNAPSHOT-tomcat.jar, which cuts out everything very
> >> close to the way we've now done it in jakartaee-api-9.1-M2-SNAPSHOT.jar
> >>
> >> How do we want to handle this?
> >>
> >> Seems our options are:
> >>
> >> A. Leave jakartaee-api-X.jar and jakartaee-api-X-tomcat.jar nearly
> >> identical in missing many specs. There is no uber jar people can
> compile
> >> against that has most everything. People would need to discover which
> >> specs are missing and pull them in individually.
> >>
> >> B. Eliminate having two jars, there is now just
> >> jakartaee-api-X-tomcat.jar (which we call jakartaee-api-X.jar). There
> is
> >> no uber jar people can compile against that has most everything. People
> >> would need to discover which specs are missing and pull them in
> >> individually.
> >>
> >> C. Do what we did with javaee-api.jar and leave mail out while
> including
> >> other impls. There is something close to an uber, but still not quite
> as
> >> identical to the jakartaee-api jar produced at Eclipse using the Eclipse
> >> impls.
> >>
> >> D. Reverse our stance on the mail thing. There would be jakartaee-api
> >> that contained everything including mail and it would be identical to
> the
> >> jakartaee-api jar produced at Eclipse using the Eclipse impls.
> >>
> >> Not sure where I sit on this spectrum yet, throwing it out so we all can
> >> think in parallel.
> >>
> >> Is it at all possible to get a similar diff for the "-tomcat" jar?
> >>
> >>
> >> -David
> >>
> >>
> >
> >
>
Re: TomEE 9.x - from javax to jakarta namespace
Posted by Jean-Louis Monteiro <jl...@tomitribe.com>.
Forgot the big thank you to everyone and special kudos to Richard.
--
Jean-Louis Monteiro
http://twitter.com/jlouismonteiro
http://www.tomitribe.com
On Mon, Jul 4, 2022 at 10:49 AM Jean-Louis Monteiro <
jlmonteiro@tomitribe.com> wrote:
> Hi,
>
> Bumping this thread up
> Not yet at the point where I'm clear on what path to use regarding the
> API, but it's been a while so I wanted to provide some status.
>
> You may have noticed the VOTE thread going on regarding TomEE 9.0.0-M2.
> This is the first real milestone for TomEE with the actual source code
> migrated to jakarta. It means that full packaged distributions (WebProfile,
> MicroProfile, Plume and Plus ZIP/TAR.GZ) should be mostly working. But the
> application composer, the JUnit support, even Arquillian are now fully
> migrated. We had to do a lot of shading/relocation of certain libraries on
> our side because libraries were not yet ready.
>
> We've worked very hard but we are finally looking good. We still have a
> few failures on our build to solve, but the platform TCK + CDI + BVal are
> looking good with less than 50 failures of 35K tests.
>
> Please remember this is a milestone and we are all still working on it.
> Any feedback is appreciated and will help.
>
> We started also upgrading our MicroProfile support to the latest one. So
> far Config, Health and Metrics are fully migrated and passing the TCK. We
> are actively working on MicroProfile JWT. And we'll be proceeding with the
> others when possible.
>
> If you haven't done it yet, please try it and feel free to vote.
>
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com
>
>
> On Thu, May 26, 2022 at 1:28 PM Jean-Louis Monteiro <
> jlmonteiro@tomitribe.com> wrote:
>
>> Hi,
>>
>> quick feedback before getting into more details
>>
>> A/ or this alternative
>> Geronimo Specs were not available in the Jakarta namespace. We are
>> starting to move some of them like Activation and Mail. Other than that, we
>> mainly have Eclipse produced APIs for Jakarta.
>> I'm not sure if we want to migrate our Geronimo Specs jars or use the
>> stock Jakarta APIs. Important note, if we do, we may not need the
>> jakartaee-api because there is already a Uber jar for Jakarta within the
>> different profiles. Should we get our user to use it as provided. And on
>> our side, should we create just a bom in our project and get the job done?
>>
>> Some APIs are also more or less implementations and vice versa. This is
>> the case for mail, faces, and some more as you mentioned. I'm fine
>> including Mail provider + Geronimo Mail spec in the jakartaee-api jar but
>> mind that in the past some users wanted to use Sun implementation and it
>> will be harder
>>
>> D/ what about inconsistencies like ...
>> Some implementations can be switched, for example Faces. Which is also a
>> mess because API and IMPL are linked together. I had previously the Faces
>> API but of course you need the implementation as well, same as for mail.
>> But Plume uses Mojorra. So we are in the situation where we need to pick
>> one or the other.
>>
>> B/ or this alternative ...
>> Tomcat classifier because we don't want to cheap with APIs already
>> provided in Tomcat with the risk of not being fully aligned. So we use
>> Tomcat APIs. Should we go the way around and remove Tomcat APIs from the
>> final distribution and get rid of the Tomcat classifier?
>>
>> Note sure if my reply is clear, hopefully it helps.
>>
>> --
>> Jean-Louis Monteiro
>> http://twitter.com/jlouismonteiro
>> http://www.tomitribe.com
>>
>>
>> On Thu, May 26, 2022 at 3:23 AM David Blevins <da...@gmail.com>
>> wrote:
>>
>>> Thanks so much for this. I even started creating one myself early this
>>> morning, ... then the rest of the day happened LOL
>>>
>>> > On May 25, 2022, at 1:56 PM, Jean-Louis Monteiro <
>>> jlmonteiro@tomitribe.com> wrote:
>>> >
>>> > Here it is
>>> >
>>> https://gist.github.com/jeanouii/9bb6c14bdde227e2fed83fd73db3a646/revisions
>>>
>>> Looks like we've yanked out Faces, JSTL, Mail, etc. I suspect we're
>>> trying to hit the line of not including APIs that are implementations. The
>>> real trick is even HttpServlet is completely dependent on the servlet
>>> container in the same way Faces, Mail, JSTL, etc are dependent on their
>>> implementations. I'm not too sure if Activation is also considered an
>>> implementation as well -- I'm not sure off-hand if there is a separate
>>> implementation jar.
>>>
>>> I know we didn't include mail in our javaee-api jar, so excluding is
>>> following that logic. I also know we have the
>>> jakartaee-api-9.1-M2-SNAPSHOT-tomcat.jar, which cuts out everything very
>>> close to the way we've now done it in jakartaee-api-9.1-M2-SNAPSHOT.jar
>>>
>>> How do we want to handle this?
>>>
>>> Seems our options are:
>>>
>>> A. Leave jakartaee-api-X.jar and jakartaee-api-X-tomcat.jar nearly
>>> identical in missing many specs. There is no uber jar people can compile
>>> against that has most everything. People would need to discover which
>>> specs are missing and pull them in individually.
>>>
>>> B. Eliminate having two jars, there is now just
>>> jakartaee-api-X-tomcat.jar (which we call jakartaee-api-X.jar). There is
>>> no uber jar people can compile against that has most everything. People
>>> would need to discover which specs are missing and pull them in
>>> individually.
>>>
>>> C. Do what we did with javaee-api.jar and leave mail out while
>>> including other impls. There is something close to an uber, but still not
>>> quite as identical to the jakartaee-api jar produced at Eclipse using the
>>> Eclipse impls.
>>>
>>> D. Reverse our stance on the mail thing. There would be jakartaee-api
>>> that contained everything including mail and it would be identical to the
>>> jakartaee-api jar produced at Eclipse using the Eclipse impls.
>>>
>>> Not sure where I sit on this spectrum yet, throwing it out so we all can
>>> think in parallel.
>>>
>>> Is it at all possible to get a similar diff for the "-tomcat" jar?
>>>
>>>
>>> -David
>>>
>>>
>>
>>