>> May be being the RI prevents major evolution/révolution ? > > Tomcat isn't the RI and hasn't been for some time.
Up to 2.5/2.1 ? >> Tomcat Light is a good idea but only costin works on it. > If you like the idea, help him out. Why should we still get this kind of reply on Tomcat list ? ;-( I won't speak for Costin but I didn't have such time to works on Tomcat. And for such project we need full time people involved. The idea is to attract a community on it and GSoC is a great opportunity. >> Asf has a great server framework, mina, but it's not used by Tc. > I'm not sure building Tomcat on top of another framework is a good idea. If > you > have a PoC that shows otherwise that would be very interesting. Mina is also ASF and why not speak with the MINA team ? May be they'll more than interesting working on such area. >> Osgi is getting more and more adoption > True. Indeed >> and Eclipse or Felix select Jetty as their http implementation. > Back to size / ease of embedding. > >> Maven has never been used as build system and 10 years after Tc is still >> stick with ant. > And what, exactly is wrong with Ant? It does the job we need it to do and it > is > far simpler to work with than Maven. This has been discussed before and the > conclusion then was that the pain wasn't worth the gain. I don't see anything > that has changed that. That's a reccurent part of the problem on the tomcat-dev list. Why should we change something working ? Maven arguments exist and you just can't say, it works with ant why changing anything ? How many major projects in ASF (and elsewhere) switched to Maven ? It will really help make Tomcat more modular, maven modules will split the complexity in more parts. And modules could became bundles easily via maven-felix-plugin. >> No luck, we couldn't use the maven modules approach for tc. Modules >> would have helped the transition to Bundle. > We don't have to use Maven to build a more modular Tomcat. May be but with a big build.xml instead of many small poms ? >>>> Probably it didn't help/allow new peoples join the project and add >>>> some fresh air & ideas ? >>> We could probably be more responsive / encouraging. I am trying to get >>> a couple >>> of GSoC projects for Tomcat this year. Hopefully that will generate >>> something. >> >> Good but may be too late ;-( > Better late than never. >> That's why i wonder if tc 7.0 will just implements what 3.0 >> requierements or will be a major evolution ? >> >> My wishes for tc 7 and later : >> >> A very small core for faster start and better embedded use. >> >> Valves/filters/whatever should be just plugable modules. Here also OSGI >> / Felix / ServiceMixKernel have many good ideas to use. >> >> Maven as a build system should be seriously reconsidered, modularity, >> artifacts depots, osgi support will be easier >> >> Tomcat project should use and share components from others ASF >> projects, Mina, Felix, ServiceMix, Commons have great stuff that could >> (should) be used. It will even be attractive for new commiters from >> these ASF project. >> >> That's my wishes for Tomcat, not just code, bits and specs compliance, >> but recreate a new wider commiters/contributors community. > > So start making contributions to take Tomcat in this direction. I'll be happy to spent some personal time (not during my job time), but there should be a real acceptance here. Maven use : I worked some times ago on a mavenised version of Tomcat. As it required a different source structure, I moved all sources to a new layout. And to automatize it, you should use some ant script before so it's clearly unfriendly (and unusual for maven developpers conventions/standardization) Openess : Did the Tomcat community want to share and use components ? Mina could provide some components. Felix could use Tomcat as it HTTP implementation instead of Jetty. ... OSGI : Did Tomcat 7 should use an OSGI core and use it dynamic bundles model to load on demand module (a sort of on demand HTTPd modules) ? The discussion is open and please don't just reply "make contributions". Ideas are contributions, not just code. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
