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 Thu, 27 Jul 2006 21:05:19 GMT
We still need some votes on GERONIMO-2223.  This is the RTC that  
moves genesis out of the sandbox.  GERONIMO-2219 is built using  
genesis and so you guys already kinda reviewed/tested it.  But the  
RTC issue is separate because it is logically different than the merge,

Please review and vote on this guy too:


On Jul 27, 2006, at 1:58 PM, Jeff Genender wrote:

> You have them.  Matt's comment looks like a +1 and you have Jacek  
> and mine.
> Jeff
> Jason Dillon wrote:
>> 2 down... 1 to go.  Any PMC member want to be the lucky third?
>> --jason
>> On Jul 27, 2006, at 1:10 PM, Jacek Laskowski (JIRA) wrote:
>>>     [
>>> page=comments#action_12423904
>>> ]
>>> Jacek Laskowski commented on GERONIMO-2219:
>>> -------------------------------------------
>>> Build, tested and am confident they can go to the trunk. Here  
>>> goes my
>>> +1 for the work that's been done in the m2migration branch, i.e. for
>>> applying the G-2219 to trunk.
>>> I do second Matt's view on it (but I'd vote +1 without it, too,  
>>> as the
>>> tests I've done finished successfully and although there may be some
>>> issues they're almost invisible for end users).
>>> Good job Jason, Anita and Prasad! I'm going on a 2-week holiday and
>>> wish to see fully functional M2 build before I return =)
>>>> [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