> creates confusion in the long run and gives the impression it is > outdated. Tomcat 7 will be eoled "soon", for example.
Good point. We once had a 'tomcat' module which was for tomcat6. Tomcat7 introduced a new API which we utilised. Thus the name. That API still exists. The only thing which kept us from renaming it back to tomcat is that we didn't want to change the maven groupId/artifactId tupple. I'd say we are very supportive of having a single point where the latest and greatest version of that plugin exists. I personally don't care much where that is. We are all a big family after all. The only real requirement is that it is well maintained and regularly released. This is similar to the tomcat maven integration which sadly is an outdated pain. Once it was extremely good, but without proper releases - as part of the standard release cycle - it became increasingly problematic. And that's what I fear if we solely have the integration on tomcat side for owb too. It would need to be part of the core. And tomcat would finally need to get a proper build system ;) There is also the technical aspect with the integration. I suspect that tomcat provides an SPI which is really generic. Wheras the OWB side of the integration is usind the webbeans-web module as base plus a few internal tricks. We could see the webbeans-web module as SPI which is _rather_ stable, but was not strictly handled as SPI by us. The question therefore is which part of the integration is more fluent and likely to change more often? tomcats SPI or the OWB side? We should put the integration on the side which is more likely to change in the future. LieGrue, strub > Am 29.06.2020 um 23:33 schrieb Rémy Maucherat <r...@apache.org>: > > On Mon, Jun 29, 2020 at 1:54 PM Romain Manni-Bucau <rmannibu...@gmail.com > <mailto:rmannibu...@gmail.com>> > wrote: > >> +1 to drop jms module, never saw any usage of it >> -0.5 for tomcat7, rational being that if we want to do it, we should (at >> the same time) 1. ensure tomcat module is at least 1-1 (not the case I >> think) + released properly and not just a sandbox and 2. drop jetty >> integration too (which can be envisioned since we worked to integrate OWB >> in jetty itself) but dropping tomcat7 module without these two conditions >> looks like an user regression to me. >> > > I would think you should keep "tomcat7" too, it's not really the same idea > as modules/owb. The main problem is using a version number in the module > name, that creates confusion in the long run and gives the impression it is > outdated. Tomcat 7 will be eoled "soon", for example. > > Rémy > > >> >> I guess ee modules can move to tomee too - any other consumer - with the >> relevant adaptations to our codebase? >> >> 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 lun. 29 juin 2020 à 13:38, Gurkan Erdogdu <cgurkanerdo...@gmail.com> a >> écrit : >> >>> Hi folks >>> I would like to discuss to remove the following modules from the OWB code >>> base. >>> >>> - webbeans-jms : We introduced this module years ago for JMS but >> frankly >>> never see any usage. Also, it was not completed. >>> - webbeans-tomcat7 : We introduced this modules for Tomcat7 >> integration >>> but now it is useless and Tomcat already includes this integration >> with >>> more natural way ( >>> https://github.com/apache/tomcat/tree/master/modules/owb) >>> >>> WDYT? Any objection? >>> Regards. >>> Gurkan
