[jira] Commented: (GERONIMO-2219) [RTC] Merge m2migration (functional m2 build) to trunk
[ 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):
[jira] Commented: (GERONIMO-2219) [RTC] Merge m2migration (functional m2 build) to trunk
[ http://issues.apache.org/jira/browse/GERONIMO-2219?page=comments#action_12425390 ] Jason Dillon commented on GERONIMO-2219: FYI, I will do this when I get back to Cali on friday... sorry have not had time to apply after the super speedy vote [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 idrepo.mergere.com/id urlhttp://repo.mergere.com/maven2/url mirrorOfcentral/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
[jira] Commented: (GERONIMO-2219) [RTC] Merge m2migration (functional m2 build) to trunk
[ 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}
[jira] Commented: (GERONIMO-2219) [RTC] Merge m2migration (functional m2 build) to trunk
[ http://issues.apache.org/jira/browse/GERONIMO-2219?page=comments#action_12423914 ] Jeff Genender commented on GERONIMO-2219: - +1...go for it. [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 idrepo.mergere.com/id urlhttp://repo.mergere.com/maven2/url mirrorOfcentral/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
Re: [jira] Commented: (GERONIMO-2219) [RTC] Merge m2migration (functional m2 build) to trunk
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
Re: [jira] Commented: (GERONIMO-2219) [RTC] Merge m2migration (functional m2 build) to trunk
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
[jira] Commented: (GERONIMO-2219) [RTC] Merge m2migration (functional m2 build) to trunk
[ http://issues.apache.org/jira/browse/GERONIMO-2219?page=comments#action_12423921 ] Matt Hogstrom commented on GERONIMO-2219: - Ok, That's 3 +1's from PMC membersgo do your vodoo. [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 idrepo.mergere.com/id urlhttp://repo.mergere.com/maven2/url mirrorOfcentral/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
Re: [jira] Commented: (GERONIMO-2219) [RTC] Merge m2migration (functional m2 build) to trunk
On 7/27/06, Jason Dillon [EMAIL PROTECTED] wrote: 2 down... 1 to go. Any PMC member want to be the lucky third? After Jeff's you've got three. It's your turn then. Will watch all your steps...mind them! ;-) Jason must be one of the happiest men in the world, mustn't he? Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: [jira] Commented: (GERONIMO-2219) [RTC] Merge m2migration (functional m2 build) to trunk
We still need some votes on GERONIMO-2223. This is the RTC that moves genesis out of the sandbox. GERONIMO-2219 is built using genesis and so you guys already kinda reviewed/tested it. But the RTC issue is separate because it is logically different than the merge, Please review and vote on this guy too: http://issues.apache.org/jira/browse/GERONIMO-2223 --jason On Jul 27, 2006, at 1:58 PM, Jeff Genender wrote: 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}}
Re: [jira] Commented: (GERONIMO-2219) [RTC] Merge m2migration (functional m2 build) to trunk
Well, I certainly was not expecting this kinda of speedy response ;-) Still need you guys to bless this: http://issues.apache.org/jira/browse/GERONIMO-2223 --jason On Jul 27, 2006, at 2:02 PM, Jacek Laskowski wrote: On 7/27/06, Jason Dillon [EMAIL PROTECTED] wrote: 2 down... 1 to go. Any PMC member want to be the lucky third? After Jeff's you've got three. It's your turn then. Will watch all your steps...mind them! ;-) Jason must be one of the happiest men in the world, mustn't he? Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: [jira] Commented: (GERONIMO-2219) [RTC] Merge m2migration (functional m2 build) to trunk
On Jul 27, 2006, at 2:02 PM, Jacek Laskowski wrote: Jason must be one of the happiest men in the world, mustn't he? Um... I can think of several reasons that I might be happier :-P * * * I will merge this back when I finish setting up my new Mac Book Pro :-) --jason
[jira] Commented: (GERONIMO-2219) [RTC] Merge m2migration (functional m2 build) to trunk
[ http://issues.apache.org/jira/browse/GERONIMO-2219?page=comments#action_12423162 ] Aaron Mulder commented on GERONIMO-2219: I see a lot of complaints POM for XYZ is invalid... Not a v4.0.0 POM and CHECKSUM FAILED. At some later date, we should massage things if we can to avoid using both concurrent and backport-util-concurrent. What is the correct command to run to restart the build (without a full bootstrap cycle) if it fails on account of a transient failure or you just want to catch any updates that you just checkout out or something like that? (old maven new) Are there still ways to rebuild all the configs without waiting for it to visit all the modules first? (old maven new4 new5) [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
[jira] Commented: (GERONIMO-2219) [RTC] Merge m2migration (functional m2 build) to trunk
[ http://issues.apache.org/jira/browse/GERONIMO-2219?page=comments#action_12423165 ] Jason Dillon commented on GERONIMO-2219: {quote} I see a lot of complaints POM for XYZ is invalid... Not a v4.0.0 POM and CHECKSUM FAILED. {quote} Maven2 likes to bitch endlessly about stuff that is mostly harmless. We will eventually trim this down as we fix up dependencies (trim some, get some poms fixed, etc). *NOTE:* If we had our own definitive repository I would have fixed these already. {quote} What is the correct command to run to restart the build (without a full bootstrap cycle) {quote} Assuming you have already gotten past the build of openejb2, then: {noformat} ./build {noformat} or: {noformat} mvn -Dstage=bootstrap mvn -Dstage=assemble {noformat} The former is just a helper to run the above, and makes it easy to pass in the same flags to both. If you failed somewhere building openejb2, then: {noformat} ./bootstrap openejb2 ./build {noformat} {quote} Are there still ways to rebuild all the configs without waiting for it to visit all the modules first? {quote} Assuming that you have built modules (and m2-plugins) at least once and just want build configs, you can: {noformat} cd configs mvn {noformat} [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
[jira] Commented: (GERONIMO-2219) [RTC] Merge m2migration (functional m2 build) to trunk
[ http://issues.apache.org/jira/browse/GERONIMO-2219?page=comments#action_12423166 ] Aaron Mulder commented on GERONIMO-2219: I saw ActiveMQ 3.2.4 coming down (I think during the configs build) -- I thought G 1.2 had switched to ActiveMQ 4.x. Any idea what's happening here? Could it be a transitive dependency? [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 idrepo.mergere.com/id urlhttp://repo.mergere.com/maven2/url mirrorOfcentral/mirrorOf /mirror /mirrors /settings {code} Also, due to the coupling of Geronimo and OpenEJB2, OpenEJB2 must be
[jira] Commented: (GERONIMO-2219) [RTC] Merge m2migration (functional m2 build) to trunk
[ http://issues.apache.org/jira/browse/GERONIMO-2219?page=comments#action_12423169 ] Aaron Mulder commented on GERONIMO-2219: The M2 build no longer inserts META-INF/geronimo-plugin.xml into the CARs that have src/conf/geronimo-plugin.xml. There was handling for this in the M1 build (e.g. for the welcome app and other examples). I'd like to see that fixed before this becomes the preferred build. I assume this would require a change in the Maven car plugin. [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 idrepo.mergere.com/id urlhttp://repo.mergere.com/maven2/url
Re: [jira] Commented: (GERONIMO-2219) [RTC] Merge m2migration (functional m2 build) to trunk
Please fill out any more details here: https://issues.apache.org/jira/browse/GERONIMO-2225 --jason On Jul 24, 2006, at 2:50 PM, Aaron Mulder (JIRA) wrote: [ http://issues.apache.org/jira/browse/GERONIMO-2219? page=comments#action_12423169 ] Aaron Mulder commented on GERONIMO-2219: The M2 build no longer inserts META-INF/geronimo-plugin.xml into the CARs that have src/conf/geronimo-plugin.xml. There was handling for this in the M1 build (e.g. for the welcome app and other examples). I'd like to see that fixed before this becomes the preferred build. I assume this would require a change in the Maven car plugin. [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
[jira] Commented: (GERONIMO-2219) [RTC] Merge m2migration (functional m2 build) to trunk
[ http://issues.apache.org/jira/browse/GERONIMO-2219?page=comments#action_12423176 ] Jason Dillon commented on GERONIMO-2219: {quote} I saw ActiveMQ 3.2.4 coming down (I think during the configs build) - I thought G 1.2 had switched to ActiveMQ 4.x {quote} I am not sure that the work to configure/enable ActiveMQ 4.x has been completed yet. [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 idrepo.mergere.com/id urlhttp://repo.mergere.com/maven2/url mirrorOfcentral/mirrorOf /mirror /mirrors /settings {code} Also, due to the coupling of Geronimo and
[jira] Commented: (GERONIMO-2219) [RTC] Merge m2migration (functional m2 build) to trunk
[ 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 idrepo.mergere.com/id urlhttp://repo.mergere.com/maven2/url mirrorOfcentral/mirrorOf /mirror /mirrors /settings
[jira] Commented: (GERONIMO-2219) [RTC] Merge m2migration (functional m2 build) to trunk
[ http://issues.apache.org/jira/browse/GERONIMO-2219?page=comments#action_12423192 ] Jason Dillon commented on GERONIMO-2219: Can you make a patch against m2migration that pulls in the remaining bits? If not I can dig around and try to get something working, but I might miss something. I'd be included to use the resources plugin to filter src/main/resources/* and then include the classes/* into the car. [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 idrepo.mergere.com/id urlhttp://repo.mergere.com/maven2/url mirrorOfcentral/mirrorOf /mirror /mirrors
[jira] Commented: (GERONIMO-2219) [RTC] Merge m2migration (functional m2 build) to trunk
[ http://issues.apache.org/jira/browse/GERONIMO-2219?page=comments#action_12423230 ] 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: 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