tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject One way to maintain a tomcat fork built with maven (was: Mavenized tomcat build)
Date Sat, 11 Jul 2009 18:01:35 GMT
I'd like to apologize for the miscommunication engendered by this  
thread.  It's very clear to me that what I thought I was communicating  
did not get through.  This attempt to clarify will probably not fare  
any better :-(

I don't expect tomcat to consider changing its build system and  
certainly don't want to participate in any discussion of the tomcat  
build system.
I don't expect tomcat to release anything from trunk or any branch in  

I do suspect that there are projects that, like geronimo, use maven  
and are faced with maintaining a tomcat fork.  For such projects, (NOT  
TOMCAT ITSELF) the tools we developed at geronimo might be useful.

Once again, this is NOT a proposal for tomcat to use maven.  If you  
guys happen to decide you want to I'd be happy to give advice, but I'm  
not proposing it and don't want to talk about whether it would be a  
good idea.

On Jul 11, 2009, at 8:38 AM, Costin Manolache wrote:

> I think there are few separate issues:
> 1, If there is a patch that needs to be applied by geronimo to use
> tomcat or they are blocked by missing something from a release - we
> should review this again. I think we can do a tomcat-geronimo release
> specifically for them as worse case ( well, we did it for j2ee ref
> impl in the old days - all we need is a branch ), or make sure it gets
> in the next release,

Personally, since geronimo now has a working method of maintaining a  
fork of the 6.0 branch including the needed patches from trunk, I  
would prefer to see any development effort expended on servlet 3.0  
features.  If tomcat 7 supports servlet 3.0 and is based on trunk  
geronimo won't need a fork any more.

> 2. For Maven support - if maven can support building tomcat, I don't
> see any problem. But moving the code around and changing code just so
> we can be built by maven - I don't like that. The current patch is
> even worse - it seems to create 2 different source trees for tomat,
> and since maven can also checkout the source and people may use the
> maven-source...

Once again, this was never intended to be about the tomcat build system.

> 3. For having maven-like 'modules' with strict build and runtime
> dependencies - been there. There are plenty of large projects using
> tomcat approach - i.e. allow circular dependencies between packages
> and build either one big jar or few jars. I think the benefits of more
> reuse and code sharing are bigger than the problems - i.e. mostly not
> able to break into many directories and build with maven, and arcane
> ways to break circular dependencies.

I'm still mystified by this.  I have no problems with circular package  
dependencies within a single jar but I really don't understand why  
you'd have 2 jars neither of which can be used without the other.   
Wouldn't it be simpler for everyone to just have one jar?

> Costin
> On Fri, Jul 10, 2009 at 11:43 PM, Mladen Turk<> wrote:
>> Filip Hanik - Dev Lists wrote:
>>> If Geronimo needs a better way to download and integrate Tomcat's  
>>> JAR's
>>> lets focus on that, and not make this into another Maven vs ANT  
>>> topic, cause
>>> I don't think that was the intention.
>> Agreed.
>> However we should really find a way to deal with eclipse
>> repository since they tend to change the download system
>> quite often (only external dependency).
>> Since we cannot copy that to the ASF due to license issue
>> we could reuse the backup system on (like we did
>> for Tomcat Native until ASF resolved the crypto software issues)
>> to allow the historic builds.
>> I somehow doubt Maven can solve this problem anyhow, and
>> downloading a repo with 10+ eclipse JDT's would be insane
>> just to build eg. 6.0.20 in 5 years from now.
????? maven only downloads the dependencies you require, not entire  
repos.  Probably I don't understand what you are saying.
>> Other things is trivial, just testing the
>> with as fallback for the remaining
>> dependencies.

I didn't mention this before either but I don't understand why tomcat  
is rebuilding the eclipse code.  The released eclipse jdt jar  
available from maven central seems to work fine.

david jencks

>> Regards
>> --
>> ^(TM)
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message