geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Genender <>
Subject Re: [jira] Commented: (GERONIMO-2219) [RTC] Merge m2migration (functional m2 build) to trunk
Date Thu, 27 Jul 2006 20:58:02 GMT
You have them.  Matt's comment looks like a +1 and you have Jacek and mine.


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:
>>     [
>> ]
>> 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:
>>>             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:
>>>  *
>>> 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
>>> 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:
>> -
>> For more information on JIRA, see:

View raw message