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