Tomcat patch procedure kinda broken

[David Jencks <da...@yahoo.com>]

I was trying to figure out how to get debuggable source for our  
patched tomcat and discovered that the currently checked in patch is  
mostly a diff from the previous patch, thus kinda unusable.

I've previously complained that with our private repo system we are  
releasing code without providing very clear indications of what the  
source code is.  In the case of tomcat I'm losing hope that they will  
ever release a version from trunk that includes our patches.  I don't  
think there are any good solutions to this but what I'm thinking of  
today is...

1. write an archetype that sets up a bunch of maven projects that are  
the structure of a maven build for tomcat
2. hopefully as part of the archetype or some related plugin or at  
least a script run a bunch of svn commands to get the relevant tomcat  
source code into the maven project structure.
3. check this in
4. apply our patches and check that in.

5. build snapshots and eventually release.

This way we have source code we can vote on, a reasonable build for  
our patched tomcat, and a procedure that may not break so quickly.

Anyone have a better idea?

thanks
david jencks

Re: Tomcat patch procedure kinda broken

[David Jencks <da...@yahoo.com>]

I worked on this today. I now have a renewed appreciation of maven and  
reasonable build structure.

Tomcat has circular references between their jars so there's no way to  
build them in sequence.  Presumably they regard the ease with which  
this can be done as a major advantage of their ant build.

So, I had to modify the set of jars being built.

In case anyone wants to try this out,

Step 1
svn co https://svn.apache.org/repos/asf/geronimo/sandbox/djencks/tomcat-archetype/trunk

cd tr	unk
# initial build seems to be necessary for archetype generation to work
mvn clean install

# builds and installs archetype used in step 2
../build.sh


Step 2
Now find a handy place for your tomcat build...

#!/bin/sh

rm -rf tomcat-parent/
mvn archetype:generate\
  -DarchetypeCatalog=local\
  -DinteractiveMode=false\
  -DarchetypeGroupId=org.apache.geronimo.ext.tomcat\
  -DarchetypeArtifactId=tomcat-parent-archetype\
  -DarchetypeVersion=1.0-SNAPSHOT\
  -DgroupId=org.apache.geronimo.test.tomcat\
  -DartifactId=tomcat-parent\
  -Dversion=1.0-SNAPSHOT\
  -Dpackage=org.apache

cd tomcat-parent
chmod u+x svn-actions.sh
../svn-actions.sh

mvn clean install

# end of script


Next step is to figure out a patch.

Anyone have an idea where to put this stuff?  I'm considering  
components but it doesn't seem quite right.  rebuild?

thanks
david jencks


On Jun 7, 2009, at 8:57 AM, David Jencks wrote:

> I was trying to figure out how to get debuggable source for our  
> patched tomcat and discovered that the currently checked in patch is  
> mostly a diff from the previous patch, thus kinda unusable.
>
> I've previously complained that with our private repo system we are  
> releasing code without providing very clear indications of what the  
> source code is.  In the case of tomcat I'm losing hope that they  
> will ever release a version from trunk that includes our patches.  I  
> don't think there are any good solutions to this but what I'm  
> thinking of today is...
>
> 1. write an archetype that sets up a bunch of maven projects that  
> are the structure of a maven build for tomcat
> 2. hopefully as part of the archetype or some related plugin or at  
> least a script run a bunch of svn commands to get the relevant  
> tomcat source code into the maven project structure.
> 3. check this in
> 4. apply our patches and check that in.
>
> 5. build snapshots and eventually release.
>
> This way we have source code we can vote on, a reasonable build for  
> our patched tomcat, and a procedure that may not break so quickly.
>
> Anyone have a better idea?
>
> thanks
> david jencks