[ http://issues.apache.org/jira/browse/GERONIMO-2219?page=comments#action_12423185 ] Anita Kulshreshtha commented on GERONIMO-2219: ----------------------------------------------
The car-maven-plugin does not include the code to package geronimo-packaging.xml. The code was available in a patch on the trunk. Please see http://issues.apache.org/jira/browse/GERONIMO-2225#action_12423174. This plugin can not handle daytrader as well. > [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
