tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Remy Maucherat <r...@apache.org>
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
guess.

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

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.

Rémy



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Mime
View raw message