[
http://issues.apache.org/jira/browse/GERONIMO-2219?page=comments#action_12425843
]
Jason Dillon commented on GERONIMO-2219:
----------------------------------------
As I had expected, Rick's JavaMail changes (#421872) are causing a bit of
additional work to resolve.
I have merged from {{sandbox/svkmerge/m2migration}} to
{{sandbox/svkmerge/trunk}} and am now using {{sandbox/svkmerge/trunk}} to
resolve the JavaMail changes.
Looks like we need to add the specs/trunk build to bootstrap, since the changes
that I integrated need 1.2-SNAPSHOT for JavaMail 1.3 Specs.
I'm testing now, may have this done in an hour or so...
> [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
> Assigned To: 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