tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Remy Maucherat <>
Subject Re: [Proposal] Resurrecting storeconfig
Date Fri, 14 Dec 2012 18:21:05 GMT
On Fri, 2012-12-14 at 17:26 +0000, Mark Thomas wrote:
> > The proposal would be to move "storeconfig7/trunk" from the sandbox to
> > "modules/storeconfig" in the Tomcat 7 branch [a port to trunk, aka
> > Tomcat "8", would be coming shortly, since I believe its container API
> > would now start to be more stable].
> :)
> Merging Engine and Service are still on the Tomcat 8 TODO list but I'm
> increasingly coming to the view that it isn't worth doing. It would
> break lots of existing stuff and the benefit of the merge is marginal.
> The other largish looking changes (e.g. web.xml parsing) shouldn't
> impact much / at all on StoreConfig.
> How far away is the trunk version?

I didn't try porting or testing with trunk yet, but I don't expect it to
be too difficult if the big changes were deferred. I thought they had
already been done in trunk actually, I should have looked at the code I

> > I don't recall Tomcat 6 having
> > modules, so I don't see where storeconfig6 would live there, and as a
> > result I propose leaving it in the sandbox.
> We could create a modules in tc6.0.x/trunk
> One of your changes that I have really come to appreciate over the years
> is the single source tree. What was your reasoning for adding it in
> modules rather than the main source tree?

There's a module for the JDBC pool in Tomcat 7, so I figured storeconfig
could be a new module there, it did sound logical. But a JDBC pool is
certainly more independent of Tomcat than storeconfig. If officially
bringing it back to Tomcat 6 as well, maybe it could be in the main tree
since creating a new modules location just for it is not going to be so

Having zillions of source trees is quite trendy these days, with Maven
to glue all the pieces together. I find it harder to work with it
though, and using Ant it is just quite crazy. So I guess there are
benefits and issues.

So either option is fine with me, it could be merged in the main tree,
or it could be a module. Either way, it could create its own jar.

> > One issue I'm wondering about is the build system. After all that time,
> > I've starting using Maven instead of Ant (unbelievable, I know ...), and
> > while I am fine continuing using existing Ant build systems, I find
> > adding ones to newer components quite useless.
> It shouldn't be too hard to add another JAR to the existing Ant build.
> Once the code is in place, I'm happy to take a look.

Yes, it should not be too hard.


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

View raw message