geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Dillon <>
Subject Re: [jira] Commented: (GERONIMO-2219) [RTC] Merge m2migration (functional m2 build) to trunk
Date Mon, 24 Jul 2006 21:57:35 GMT
Please fill out any more details here:


On Jul 24, 2006, at 2:50 PM, Aaron Mulder (JIRA) wrote:

>     [ 
> page=comments#action_12423169 ]
> Aaron Mulder commented on GERONIMO-2219:
> ----------------------------------------
> The M2 build no longer inserts META-INF/geronimo-plugin.xml into  
> the CARs that have src/conf/geronimo-plugin.xml.  There was  
> handling for this in the M1 build (e.g. for the welcome app and  
> other examples).
> I'd like to see that fixed before this becomes the preferred  
> build.  I assume this would require a change in the Maven car plugin.
>> [RTC] Merge m2migration (functional m2 build) to trunk
>> ------------------------------------------------------
>>                 Key: GERONIMO-2219
>>                 URL: 
>> GERONIMO-2219
>>             Project: Geronimo
>>          Issue Type: RTC
>>      Security Level: public(Regular issues)
>>          Components: buildsystem
>>    Affects Versions: 1.2
>>            Reporter: Jason Dillon
>>            Priority: Critical
>>             Fix For: 1.2
>> h3. Overview
>> For the past few weeks we have been busy at work getting Geronimo  
>> 1.2-SNAPSHOT to build with Maven 2.  As I have noted before in  
>> email, the process is almost complete.  At this point the work  
>> done so far results in a functional server for the following  
>> assemblies:
>>  * geronimo-jetty-j2ee
>>  * geronimo-jetty-minimal
>>  * geronimo-tomcat-j2ee
>>  * geronimo-tomcat-minimal
>> The work to implement has been applied to a branch in the sandbox,  
>> and includes many submitted patches from those contributors and  
>> commiters that had been helping with the effort.
>> My recommendation is that we _merge_ this change to trunk and not  
>> generate a diff and then patch.  There are a few changes which  
>> patch does not handle well and will cause failed chunks when  
>> applied, and there are a few files moved and copied, which when  
>> patched will cause loss of that history.
>> As I mentioned this work is _almost complete_, there are still a  
>> few pending issues, please see the section below for more details.
>> h3. Recommend Action Post RTC
>> Once we have the required RTC +1's to allow this work to be  
>> merged, this is what I recommend:
>>  # Merge m2migration to trunk as described below
>>  # Deprecate the Maven1 build; meaning leave the m1 files, but  
>> strongly urge developers to use the m2 build
>>  # Enable the TCK _automated_ testing in GBuild using the m2 build
>>  # Remove the m1 build (and related files)
>> These steps will probably take a few weeks post-merge to complete.
>> h3. About the Branch
>> The main branch which should be used for review is:
>>  * 
>> m2migration
>> I have been using SVK ( ) to keep this  
>> m2migration branch up to date with the latest changes that  have  
>> been made to trunk (with a few exceptions).  I have been staging  
>> the merge as follows:
>>  * merge from {{trunk}} to {{sandbox/svkmerge/trunk}}
>>  * merge from {{sandbox/svkmerge/trunk}} {{sandbox/svkmerge/ 
>> m2migration}}
>> This has worked out very well and I have found that using SVK  
>> dramatically reduces to complexity of performing full tree (or  
>> partial tree merges).  I have been verifying that the SVK  
>> {{smerge}} is indeed doing the right thing and I have a good deal  
>> of confidence in it at this point.
>> The idea is to merge m2migration back to trunk using SVK as follows:
>>  * merge from {{sandbox/svkmerge/m2migration}} to {{sandbox/ 
>> svkmerge/trunk}}
>>  * merge from {{sandbox/svkmerge/trunk}} to {{trunk}}
>> This is the opposite of what I am performing now on a regular  
>> basis to sync this development branch.  Normally the additional  
>> branch (svkmerge/trunk) would not be needed, but it exists to help  
>> ensure that the merge is indeed _doing the right thing_.
>> h3. Recommended Review Steps
>> {noformat}
>> svn co 
>> m2migration
>> cd m2migration
>> ./bootstrap
>> gunzip -c m2-assemblies/geronimo-jetty-j2ee/target/geronimo-jetty- 
>> j2ee-1.2-SNAPSHOT-bin.tar.gz | tar xf -
>> ./geronimo-jetty-j2ee/bin/ && tail -f geronimo-jetty- 
>> j2ee/var/log/geronimo.out
>> ....
>> ./geronimo-jetty-j2ee/bin/ --user system --password  
>> manager
>> {noformat}
>> *NOTE:* Windows users need to run {{bootstrap}} from a Cygwin  
>> environment and should probably run these steps from the root of a  
>> drive (c:, d:, etc) to better ensure that the long filename  
>> problem is not an issue when testing.
>> *WARNING:* The {{bootstrap}} script will remove your local Maven2  
>> repository cache and will take maybe 30 minutes or so to run...  
>> more or less depending on how fast your network connection is.
>> You should define a mirror for the {{central}} m2 repository  
>> before running... otherwise you will almost certainly get  
>> repository failures downloading from ibiblio. This is what I am  
>> using (in ~/.m2/settings.xml):
>> {code:xml}
>> <?xml version="1.0"?>
>> <settings>
>>     <mirrors>
>>         <mirror>
>>             <id></id>
>>             <url></url>
>>             <mirrorOf>central</mirrorOf>
>>         </mirror>
>>     </mirrors>
>> </settings>
>> {code}
>> Also, due to the coupling of Geronimo and OpenEJB2, OpenEJB2 must  
>> be checked out and built in the middle of the bootstrapping.  Once  
>> G is hooked up to CI and snapshots are being automatically  
>> deployed, we can also hook up OpenEJB2 to do the same... but until  
>> then OpenEJB2 needs to be built in the bootstrap.
>> h4. Testing Caveats
>> Currently the test from the timer module may fail on systems that  
>> are slow or are low on cpu resources when the test is run.  If you  
>> run into this, you may need to disable the tests for that module  
>> by adding this to the pom:
>> {code:xml}
>> <properties>
>>     <maven.test.skip>true</maven.test.skip>
>> </properties>
>> {code}
>> Since the tests appear to normal work, I am uncomfortable turning  
>> them off by default... and we will eventually fix them.  Tracked by:
>>  *
>> You may run into problems downloading artifacts while  
>> bootstrapping, specifically I have seen the Apache m1 repos reject  
>> connections and cause the build to fail.  Re-running will  
>> resolve.  Make sure you have a mirror configured for central.
>> h3. Pending Issues
>> There are still a few remaining issues which need to be sorted out.
>> Rick's JavaMail changes (#421872) which remove the javamail- 
>> transport module have yet to be applied due to the lack of the  
>> deployed dependency.
>> Some use of version properties in pom.xml files are inconsistent  
>> due to selective use by child pom's that can not easily make use  
>> of the {{<dependencyManagement>}} section; which is the desired  
>> end result.  It will take some time to refactor to get this really  
>> finished.
>> Some minor work is needed to get the jsp/servlet examples happy.   
>> Also need to resolve the geronimo-samples groupId (and more so  
>> where that source comes from).
>> Some (2 actually) test failures need to have some attention given  
>> to them, tracked be:
>>  *
>>  *
>> Some more work also needs to be done on the Maven-2 generated  
>> site, but there is most of it here already:
>>  *
>> h3. What if 'bootstrap' Fails?
>> So far, most of the failures that people run into are due to  
>> environmental causes and not because of anything broken with the  
>> branch or build configuration.
>> If you run into any failure, please mail dev@ and include the  
>> bootstrap.log, which should be generated automatically and  
>> captures all output.
> -- 
> This message is automatically generated by JIRA.
> -
> If you think it was sent incorrectly contact one of the  
> administrators: 
> Administrators.jspa
> -
> For more information on JIRA, see: 
> software/jira

View raw message