Jakarta EE APIs

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Jakarta EE APIs

Mark Thomas-2
Hi all,

We currently have implementations for all of the Jakarta APIs that ship with Tomcat and partial implementations for 5 additional Jakarta APIs that are compile time only dependencies.

I was checking those partial implementations earlier today when I noticed the Jakarta Mail API needed updating to use generics. I started on that but paused when it looked like a number of new (dummy) classes would be required.

Considering alternative options, I wondered about depending on the Jakarta API JARs directly. This would be a return to the 5.5.x era approach without  hopefully, the issue that JARs could be difficult to obtain.

I have this implemented locally. It removes about 1000 lines of .java files (although just under 10% of them are actual code) and adds about 100 lines of build file config and anither 50 of IDE configuration.

With the Jakarta JARs being readily available in Maven Central I think the primary issue that led to the current approach is no longer a concern.

Thoughts on switching to using the JARs directly? I can provide a PR if that is helpful.

Mark

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Jakarta EE APIs

Mark Thomas-2
On 22/07/2020 15:53, Mark Thomas wrote:

> Hi all,
>
> We currently have implementations for all of the Jakarta APIs that ship with Tomcat and partial implementations for 5 additional Jakarta APIs that are compile time only dependencies.
>
> I was checking those partial implementations earlier today when I noticed the Jakarta Mail API needed updating to use generics. I started on that but paused when it looked like a number of new (dummy) classes would be required.
>
> Considering alternative options, I wondered about depending on the Jakarta API JARs directly. This would be a return to the 5.5.x era approach without  hopefully, the issue that JARs could be difficult to obtain.
>
> I have this implemented locally. It removes about 1000 lines of .java files (although just under 10% of them are actual code) and adds about 100 lines of build file config and anither 50 of IDE configuration.
>
> With the Jakarta JARs being readily available in Maven Central I think the primary issue that led to the current approach is no longer a concern.
>
> Thoughts on switching to using the JARs directly? I can provide a PR if that is helpful.

For clarity, I'm only proposing to do this for Tomcat 10 where at least
one of these APIs has changes other than just a package rename. I don't
see the benefit in doing this for Tomact 9 and earlier.

Mark

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Jakarta EE APIs

Romain Manni-Bucau
Hi Mark,

Another option is to use Apache Geronimo specs (and update/create missing ones - think new mail one is not yet there for ex).
Advantage would be we wouldn't lose all the work around OSGi and jpms eclipse does not - and will not probably - handle (at least for the first part).
It also cleans up the legal work for Tomcat as a small side bonus.

Romain Manni-Bucau
@rmannibucau |  Blog | Old BlogGithub | LinkedIn | Book


Le mer. 22 juil. 2020 à 17:53, Mark Thomas <[hidden email]> a écrit :
On 22/07/2020 15:53, Mark Thomas wrote:
> Hi all,
>
> We currently have implementations for all of the Jakarta APIs that ship with Tomcat and partial implementations for 5 additional Jakarta APIs that are compile time only dependencies.
>
> I was checking those partial implementations earlier today when I noticed the Jakarta Mail API needed updating to use generics. I started on that but paused when it looked like a number of new (dummy) classes would be required.
>
> Considering alternative options, I wondered about depending on the Jakarta API JARs directly. This would be a return to the 5.5.x era approach without  hopefully, the issue that JARs could be difficult to obtain.
>
> I have this implemented locally. It removes about 1000 lines of .java files (although just under 10% of them are actual code) and adds about 100 lines of build file config and anither 50 of IDE configuration.
>
> With the Jakarta JARs being readily available in Maven Central I think the primary issue that led to the current approach is no longer a concern.
>
> Thoughts on switching to using the JARs directly? I can provide a PR if that is helpful.

For clarity, I'm only proposing to do this for Tomcat 10 where at least
one of these APIs has changes other than just a package rename. I don't
see the benefit in doing this for Tomact 9 and earlier.

Mark

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Jakarta EE APIs

Mark Thomas-2
On 22/07/2020 17:11, Romain Manni-Bucau wrote:
> Hi Mark,
>
> Another option is to use Apache Geronimo specs (and update/create
> missing ones - think new mail one is not yet there for ex).

This is a distinct disadvantage.

> Advantage would be we wouldn't lose all the work around OSGi and jpms
> eclipse does not - and will not probably - handle (at least for the
> first part).

As compile time only JARs OSGi and JPMS are not a factor.

> It also cleans up the legal work for Tomcat as a small side bonus.

They are all EPLv2 licensed and compile time only so there isn't any
legal work required.

Mark


>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github
> <https://github.com/rmannibucau> | LinkedIn
> <https://www.linkedin.com/in/rmannibucau> | Book
> <https://www.packtpub.com/application-development/java-ee-8-high-performance>
>
>
> Le mer. 22 juil. 2020 à 17:53, Mark Thomas <[hidden email]
> <mailto:[hidden email]>> a écrit :
>
>     On 22/07/2020 15:53, Mark Thomas wrote:
>     > Hi all,
>     >
>     > We currently have implementations for all of the Jakarta APIs that
>     ship with Tomcat and partial implementations for 5 additional
>     Jakarta APIs that are compile time only dependencies.
>     >
>     > I was checking those partial implementations earlier today when I
>     noticed the Jakarta Mail API needed updating to use generics. I
>     started on that but paused when it looked like a number of new
>     (dummy) classes would be required.
>     >
>     > Considering alternative options, I wondered about depending on the
>     Jakarta API JARs directly. This would be a return to the 5.5.x era
>     approach without  hopefully, the issue that JARs could be difficult
>     to obtain.
>     >
>     > I have this implemented locally. It removes about 1000 lines of
>     .java files (although just under 10% of them are actual code) and
>     adds about 100 lines of build file config and anither 50 of IDE
>     configuration.
>     >
>     > With the Jakarta JARs being readily available in Maven Central I
>     think the primary issue that led to the current approach is no
>     longer a concern.
>     >
>     > Thoughts on switching to using the JARs directly? I can provide a
>     PR if that is helpful.
>
>     For clarity, I'm only proposing to do this for Tomcat 10 where at least
>     one of these APIs has changes other than just a package rename. I don't
>     see the benefit in doing this for Tomact 9 and earlier.
>
>     Mark
>
>     ---------------------------------------------------------------------
>     To unsubscribe, e-mail: [hidden email]
>     <mailto:[hidden email]>
>     For additional commands, e-mail: [hidden email]
>     <mailto:[hidden email]>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Jakarta EE APIs

Romain Manni-Bucau


Le mer. 22 juil. 2020 à 18:29, Mark Thomas <[hidden email]> a écrit :
On 22/07/2020 17:11, Romain Manni-Bucau wrote:
> Hi Mark,
>
> Another option is to use Apache Geronimo specs (and update/create
> missing ones - think new mail one is not yet there for ex).

This is a distinct disadvantage.

You mean not having it handy?
Think it is 1-1 with current option except it solves the fact to have it within tomcat.



> Advantage would be we wouldn't lose all the work around OSGi and jpms
> eclipse does not - and will not probably - handle (at least for the
> first part).

As compile time only JARs OSGi and JPMS are not a factor.

> It also cleans up the legal work for Tomcat as a small side bonus.

They are all EPLv2 licensed and compile time only so there isn't any
legal work required.

Didnt check recently but think you still must bundle their license and do some notice work.


Mark


>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github
> <https://github.com/rmannibucau> | LinkedIn
> <https://www.linkedin.com/in/rmannibucau> | Book
> <https://www.packtpub.com/application-development/java-ee-8-high-performance>
>
>
> Le mer. 22 juil. 2020 à 17:53, Mark Thomas <[hidden email]
> <mailto:[hidden email]>> a écrit :
>
>     On 22/07/2020 15:53, Mark Thomas wrote:
>     > Hi all,
>     >
>     > We currently have implementations for all of the Jakarta APIs that
>     ship with Tomcat and partial implementations for 5 additional
>     Jakarta APIs that are compile time only dependencies.
>     >
>     > I was checking those partial implementations earlier today when I
>     noticed the Jakarta Mail API needed updating to use generics. I
>     started on that but paused when it looked like a number of new
>     (dummy) classes would be required.
>     >
>     > Considering alternative options, I wondered about depending on the
>     Jakarta API JARs directly. This would be a return to the 5.5.x era
>     approach without  hopefully, the issue that JARs could be difficult
>     to obtain.
>     >
>     > I have this implemented locally. It removes about 1000 lines of
>     .java files (although just under 10% of them are actual code) and
>     adds about 100 lines of build file config and anither 50 of IDE
>     configuration.
>     >
>     > With the Jakarta JARs being readily available in Maven Central I
>     think the primary issue that led to the current approach is no
>     longer a concern.
>     >
>     > Thoughts on switching to using the JARs directly? I can provide a
>     PR if that is helpful.
>
>     For clarity, I'm only proposing to do this for Tomcat 10 where at least
>     one of these APIs has changes other than just a package rename. I don't
>     see the benefit in doing this for Tomact 9 and earlier.
>
>     Mark
>
>     ---------------------------------------------------------------------
>     To unsubscribe, e-mail: [hidden email]
>     <mailto:[hidden email]>
>     For additional commands, e-mail: [hidden email]
>     <mailto:[hidden email]>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Jakarta EE APIs

remm
In reply to this post by Mark Thomas-2
On Wed, Jul 22, 2020 at 5:10 PM Mark Thomas <[hidden email]> wrote:
Hi all,

We currently have implementations for all of the Jakarta APIs that ship with Tomcat and partial implementations for 5 additional Jakarta APIs that are compile time only dependencies.

I was checking those partial implementations earlier today when I noticed the Jakarta Mail API needed updating to use generics. I started on that but paused when it looked like a number of new (dummy) classes would be required.

Considering alternative options, I wondered about depending on the Jakarta API JARs directly. This would be a return to the 5.5.x era approach without  hopefully, the issue that JARs could be difficult to obtain.

I have this implemented locally. It removes about 1000 lines of .java files (although just under 10% of them are actual code) and adds about 100 lines of build file config and anither 50 of IDE configuration.

With the Jakarta JARs being readily available in Maven Central I think the primary issue that led to the current approach is no longer a concern.

Thoughts on switching to using the JARs directly? I can provide a PR if that is helpful.

Ok, +1 to try it.

Rémy
 

Mark

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Jakarta EE APIs

Martin Grigorov
In reply to this post by Mark Thomas-2


On Wed, Jul 22, 2020, 18:10 Mark Thomas <[hidden email]> wrote:
Hi all,

We currently have implementations for all of the Jakarta APIs that ship with Tomcat and partial implementations for 5 additional Jakarta APIs that are compile time only dependencies.

I was checking those partial implementations earlier today when I noticed the Jakarta Mail API needed updating to use generics. I started on that but paused when it looked like a number of new (dummy) classes would be required.

Considering alternative options, I wondered about depending on the Jakarta API JARs directly. This would be a return to the 5.5.x era approach without  hopefully, the issue that JARs could be difficult to obtain.

I have this implemented locally. It removes about 1000 lines of .java files (although just under 10% of them are actual code) and adds about 100 lines of build file config and anither 50 of IDE configuration.

With the Jakarta JARs being readily available in Maven Central I think the primary issue that led to the current approach is no longer a concern.

Thoughts on switching to using the JARs directly? I can provide a

+1

PR if that is helpful. 

Mark

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Jakarta EE APIs

Raymond Auge-3
+1

- Ray

On Wed., Jul. 22, 2020, 5:29 p.m. Martin Grigorov, <[hidden email]> wrote:


On Wed, Jul 22, 2020, 18:10 Mark Thomas <[hidden email]> wrote:
Hi all,

We currently have implementations for all of the Jakarta APIs that ship with Tomcat and partial implementations for 5 additional Jakarta APIs that are compile time only dependencies.

I was checking those partial implementations earlier today when I noticed the Jakarta Mail API needed updating to use generics. I started on that but paused when it looked like a number of new (dummy) classes would be required.

Considering alternative options, I wondered about depending on the Jakarta API JARs directly. This would be a return to the 5.5.x era approach without  hopefully, the issue that JARs could be difficult to obtain.

I have this implemented locally. It removes about 1000 lines of .java files (although just under 10% of them are actual code) and adds about 100 lines of build file config and anither 50 of IDE configuration.

With the Jakarta JARs being readily available in Maven Central I think the primary issue that led to the current approach is no longer a concern.

Thoughts on switching to using the JARs directly? I can provide a

+1

PR if that is helpful. 

Mark

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]