geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: Use tomcat trunk in some way?
Date Sat, 12 Dec 2009 08:44:37 GMT
I don't think this is a satisfactory solution.  One big reason I need  
the repackaging is so I can debug tomcat and know what jar I'm looking  
at.  Since AFAICT this keeps all the source in the same file structure  
as the original tomcat project I can't figure out what's going on.

There's also a problem that it doesn't build for me, but that is  
presumably easy to fix.

I didn't really understand why you didn't use the same solution we  
used for tomcat 6.0.x.  Are the unix scripts a problem?  There's a  
possibly not-yet-released antlib that is supposed to let you run svn  
commands from ant, maybe we could use that.

thanks
david jencks

On Dec 8, 2009, at 1:35 AM, Ivan wrote:

> 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 <xhhsld@gmail.com>
> 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 <xhhsld@gmail.com>
>
> OK, I will try to do it in the next week if no one beats to it !
>
> 2009/12/3 Kevan Miller <kevan.miller@gmail.com>
>
>
> 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


Mime
View raw message