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 Sat, 12 Dec 2009 09:06:28 GMT
2009/12/12 David Jencks <david_jencks@yahoo.com>

> 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.
>
>
 For debugging,  currently, they are truely in one big project, but why do
you need to know which jar the target classes are in, could you give any
scenario ?


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

 Could you please  give any detailed info about the error ?

>
> 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.
>
>
  The reason that I used this solution is that I found that Tomcat 7 is
under heavy development, I always found many files are updated when running
svn up.  It would be an extra stuff to keep the codes consistently. Also, we
do not keep any our own patch now.
  However, I am opposed with the orginal way used in Tomcat 6.0.20, just
feel we might have another way to do it.  :-)


> 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
>
>
>


-- 
Ivan

Mime
View raw message