geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ivan <xhh...@gmail.com>
Subject Re: Use tomcat trunk in some way?
Date Tue, 08 Dec 2009 09:35:05 GMT
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