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 <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
