You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Mark Thomas <ma...@apache.org> on 2020/07/22 14:53:05 UTC
Jakarta EE APIs
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: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Jakarta EE APIs
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Le mer. 22 juil. 2020 à 18:29, Mark Thomas <ma...@apache.org> 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 <markt@apache.org
> > <ma...@apache.org>> 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: dev-unsubscribe@tomcat.apache.org
> > <ma...@tomcat.apache.org>
> > For additional commands, e-mail: dev-help@tomcat.apache.org
> > <ma...@tomcat.apache.org>
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
Re: Jakarta EE APIs
Posted by Mark Thomas <ma...@apache.org>.
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 <markt@apache.org
> <ma...@apache.org>> 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: dev-unsubscribe@tomcat.apache.org
> <ma...@tomcat.apache.org>
> For additional commands, e-mail: dev-help@tomcat.apache.org
> <ma...@tomcat.apache.org>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Jakarta EE APIs
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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 <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 <ma...@apache.org> 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: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
Re: Jakarta EE APIs
Posted by Mark Thomas <ma...@apache.org>.
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: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Jakarta EE APIs
Posted by Rémy Maucherat <re...@apache.org>.
On Wed, Jul 22, 2020 at 5:10 PM Mark Thomas <ma...@apache.org> 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: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
Re: Jakarta EE APIs
Posted by Raymond Auge <ra...@liferay.com.INVALID>.
+1
- Ray
On Wed., Jul. 22, 2020, 5:29 p.m. Martin Grigorov, <mg...@apache.org>
wrote:
>
>
> On Wed, Jul 22, 2020, 18:10 Mark Thomas <ma...@apache.org> 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: dev-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>
>>
Re: Jakarta EE APIs
Posted by Martin Grigorov <mg...@apache.org>.
On Wed, Jul 22, 2020, 18:10 Mark Thomas <ma...@apache.org> 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: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>