OK, finally, I still used our way to divide the Tomcat codes, it seems that Tomcat side did not define those artifacts correctly. I checked the codes to my sandbox. The way I used now is to create a "wrapper" project for Tomcat 7. In this way, we do not need to merge codes regularly, it should be a better solution for temporary use :-) The steps are : 1. svn co https://svn.apache.org/repos/asf/geronimo/sandbox/ivan/geronimo_tomcat_7.0.0 2. svn co https://svn.apache.org/repos/asf/tomcat/trunk Your_local_folder 3. Edit the root pom file, make the property tomcat.local.directory pointed to Your_local_folder 4. mvn clean install
I am trying to use maven-scm-plugin to make the build more automatically, but failed ;-( So need to check out Tomcat codes manually .... Currently, there are some compilation errors due to some signature conflicts with our own servlet api. Will check it later. 2009/12/7 Ivan <[email protected]> > I am trying another way to package and deploy Tomcat 7 artifacts, since it > is just a temporary solution, I think we just need to create a "wrap" pom > file, which means no source codes are copied. In this way, we could just use > scm plugin to update the source codes, and no need to merge codes by > ourselves. > e.g. > <plugin> > <groupId>org.apache.maven.plugins</groupId> > <artifactId>maven-compiler-plugin</artifactId> > <configuration> > <includes> > <include name="org/apache/catalina/**" /> > <include name="org/apache/naming/**" /> > </includes> > <excludes> > <exclude name="org/apache/catalina/ant/**" /> > <exclude name="org/apache/catalina/ha/**" /> > <exclude > name="org/apache/catalina/mbeans/JmxRemote*" /> > <exclude name="org/apache/catalina/tribes/**" /> > <exclude name="org/apache/catalina/launcher/**" /> > <exclude name="org/apache/catalina/storeconfig/**" > /> > <exclude > name="org/apache/naming/factory/webservices/**" /> > > <exclude>org/apache/naming/factory/webservices/**</exclude> > > </excludes> > </configuration> > </plugin> > > Another question is that I found that the way we divided the Tomcat codes > are not the same with its original way. > Tomcat has an artifact named coyote, while we didn't. > Is there any story about it ? If no special reason, I would like keep the > same with Tomcat's. > Thanks ! > > > 2009/12/3 Ivan <[email protected]> > > OK, I will try to do it in the next week if no one beats to it ! >> >> 2009/12/3 Kevan Miller <[email protected]> >> >> >>> On Dec 2, 2009, at 11:51 AM, David Jencks wrote: >>> >>> > >>> > On Dec 2, 2009, at 1:57 AM, Ivan wrote: >>> > >>> >> I am thinking whether there is maven plugin would help us to repackge >>> the tomcat jar file to include our changes, so that we do not need to >>> maintain the whole Tomcat source codes, maybe just need to keep a few files. >>> > >>> > AFAIK tomcat is not pushing trunk snapshots into any maven repo, so I >>> think we'd have to build tomcat ourselves anyway. Given that, I think that >>> the easiest way is to use the process for constructing a mavenized build. >>> I'm hoping we won't actually need to modify any files, at least not for >>> long :-). The first set of changes we needed that led me to set up the >>> mavenized build have been in tomcat trunk for years. >>> >>> Right. So, if the motivation for this process is to make Tomcat >>> SNAPSHOT's available in maven, I'm ok with this. I would not want to see >>> this as a way of fixing functional/integration problems with Tomcat (at >>> least not in the long-term). >>> >>> --kevan >> >> >> >> >> -- >> Ivan >> > > > > -- > Ivan > -- Ivan
