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 Mon, 14 Dec 2009 23:06:06 GMT
Now that I've tried it.... an update

To generate a new snapshot...

svn rm -m "GERONIMO-4980 remove old version to make way for new" https://svn.apache.org/repos/asf/geronimo/external/trunk/tomcat-parent-7.0.0
./run.sh
svn commit -m "GERONIMO-4980 new tomcat snapshot at rev XXXX" tomcat- 
parent-7.0.0
rm -rf tomcat-parent-7.0.0
svn up tomcat-parent-7.0.0

thanks
david jencks
On Dec 13, 2009, at 1:58 AM, David Jencks wrote:

> I couldn't make IDEA understand how to debug in this approach so I  
> updated the tomcat-archetype to work with tomcat 7 and added  
> external/trunk/tomcat-parent-7.0.0 generated with the archetype.
>
> To reproduce this, update external/tomcat-archetype and build the  
> archetype using
> svn up tomcat-archetype
> cd tomcat-archetype
> ./build-archetype.sh
> cp run.sh ..
> cd ..
> ./run.sh
>
> This will construct a tomcat-7 project from the archetype and latest  
> tomcat code, ready to commit.  When I committed svn got confused  
> updating the local copy so you may need to
> svn commit -m "new tomcat 7 snapshot based on tomcat rev xxxxxx"  
> tomcat-parent-7.0.0
> rm -rf tomcat-parent-7.0.0
> svn up tomcat-parent-7.0.0
>
> Once you have run.sh in position, to generate a new snapshot just  
> run ./run.sh again.  It will remove the old tomcat-parent-7.0.0  
> project and add the new one.
>
> This only works on unix like systems but I'd imagine it would work  
> with cygwin.
>
> Anyway this let me start tracking down the maven jspc plugin  
> problem, I've asked on the tomcat list for advice on how to proceed.
>
> thanks
> david jencks
>
>
>
>
> On Dec 12, 2009, at 1:06 AM, Ivan wrote:
>
>>
>>
>> 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