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: > >> [ >> http://issues.apache.org/jira/browse/GERONIMO-2219?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: http://issues.apache.org/jira/browse/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: >>> * >>> https://svn.apache.org/repos/asf/geronimo/sandbox/svkmerge/m2migration >>> I have been using SVK ( http://svk.elixus.org/ ) 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 >>> https://svn.apache.org/repos/asf/geronimo/sandbox/svkmerge/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/startup.sh && tail -f >>> geronimo-jetty-j2ee/var/log/geronimo.out >>> .... >>> ./geronimo-jetty-j2ee/bin/shutdown.sh --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>repo.mergere.com</id> >>> <url>http://repo.mergere.com/maven2</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: >>> * https://issues.apache.org/jira/browse/GERONIMO-2183 >>> 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. >>> https://issues.apache.org/jira/browse/GERONIMO-2206 >>> 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: >>> * https://issues.apache.org/jira/browse/GERONIMO-2210 >>> * https://issues.apache.org/jira/browse/GERONIMO-2211 >>> Some more work also needs to be done on the Maven-2 generated site, >>> but there is most of it here already: >>> * http://geronimo.apache.org/maven/ >>> 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: http://issues.apache.org/jira/secure/Administrators.jspa >> - >> For more information on JIRA, see: http://www.atlassian.com/software/jira >> >>
