geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Matt Hogstrom (JIRA)" <>
Subject [jira] Commented: (GERONIMO-2219) [RTC] Merge m2migration (functional m2 build) to trunk
Date Tue, 25 Jul 2006 04:50:14 GMT
    [ ] 
Matt Hogstrom commented on GERONIMO-2219:

Here is my 2c.

I tested the build out tonight and was able to get a runnable server.  IMHO this change is
way too complicated for a patch and is taking far too long (no offense to anyone working on
the conversion but more of a comment on our current process).

I'm inclined to +1 the work Jason has done and move this to trunk.  Then we all work through
the issues.  Jason and others have been very diligent in working on this conversion (which
is in several months now I think).

Based on the responsiveness of Jason, Prasad and Anita I don't see a tremendopus amount of
harm in doing the merge and getting this done in trunk.  Its not ideal but one doesn't rework
the entire build system every release.

I propose we +1 it...suck it up...and work with Jason to get this done.  It will be painful
for everyone but I think right now Jason, Prasad and Anita are suffering way too much.

This isn't a server feature...this is a build system.  Its bigger than a bread box.  We all
know what we're doing and its time to get this done.

Things will be broken...and they will get fixed.

> [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