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