Re: Jakarta EE APIs

[Raymond Auge]

+1

- Ray

On Wed., Jul. 22, 2020, 5:29 p.m. Martin Grigorov, 
wrote:

>
>
> On Wed, Jul 22, 2020, 18:10 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
>
>
> +1
>
> PR if that is helpful.
>
>
>> Mark
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: dev-h...@tomcat.apache.org
>>
>>

Re: Jakarta EE APIs

[Martin Grigorov]

On Wed, Jul 22, 2020, 18:10 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


+1

PR if that is helpful.


> Mark
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

Re: Jakarta EE APIs

[Rémy Maucherat]

On Wed, Jul 22, 2020 at 5:10 PM 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.
>

Ok, +1 to try it.

Rémy


>
> Mark
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

Re: Jakarta EE APIs

[Romain Manni-Bucau]

Le mer. 22 juil. 2020 à 18:29, Mark Thomas  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  |  Blog
> >  | Old Blog
> >  | Github
> >  | LinkedIn
> >  | Book
> > <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
> >
> >
> > Le mer. 22 juil. 2020 à 17:53, Mark Thomas  > > 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-unsubscr...@tomcat.apache.org
> > 
> > For additional commands, e-mail: dev-h...@tomcat.apache.org
> > 
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

Re: Jakarta EE APIs

[Mark Thomas]

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  |  Blog
>  | Old Blog
>  | Github
>  | LinkedIn
>  | Book
> 
> 
> 
> Le mer. 22 juil. 2020 à 17:53, Mark Thomas  > 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-unsubscr...@tomcat.apache.org
> 
> For additional commands, e-mail: dev-h...@tomcat.apache.org
> 
> 


-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

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 Blog
 | Github  |
LinkedIn  | Book



Le mer. 22 juil. 2020 à 17:53, Mark Thomas  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-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

Re: Jakarta EE APIs

[Mark Thomas]

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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org