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

Reply via email to