tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Thomas <>
Subject Re: [Proposal] Remove older of the two BIO AJP connectors
Date Thu, 02 Apr 2009 10:13:41 GMT
Henri Gomez wrote:
>>> 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 ? ;-(
Because you are criticizing the direction things are going but making little to
no contribution to moving Tomcat forward in the direction you think it should be

> The idea is to attract a community on it and GSoC is a great opportunity.
+1. Any help/advice you want to give to the prospective students would be very
much appreciated as they as their questions on the dev list.

>>> 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.
Again, if *you* want to pursue this / think this is a good idea - *you* need to
invest the time to pursue this / persuade others that it is worth them pursuing.

>>> 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 ?
Exactly. If it ain't broke don't fix it. There is always scope to do things
better but the reward has to be worth the effort required. That case has yet to
be made (in my view) for switching to Maven.

> Maven arguments exist and you just can't say, it works with ant why
> changing anything ?
They do but the last time someone tried to make them, the argument wasn't

> How many major projects in ASF (and elsewhere) switched to Maven ?
No idea.

> 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 ?
Which is fine by me right now.

If there was a compelling argument to switch to Maven and go through the
associated learning curve I would be +1 for the switch. I have yet to see a
compelling argument.

>>> 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.
You need to make the case for each of these changes. If there is a case then I
for one would be +1.

> 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)
As I said above, I don't see that the pain is worth the gain. I'm happy to be
convinced otherwise.

> 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.
I'm all for code re-use where we can. That is one of the reasons I am working on
the Commons components that Tomcat uses.

Any re-use is always going to be a trade off. Each case will need to be looked
at on it's merits but where it makes sense to do so it will get a +1 from me.

> 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) ?
That is an awfully big step from where we are now. How do you propose we get
from where we are to a set of bundles running on an OSGI framework?

> The discussion is open and please don't just reply "make contributions".
> Ideas are contributions, not just code.

+1 but without contributions the ideas are unlikely to get anywhere


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message