Re: [RTC] Vote on GERONIMO-2161 - restart 1
On 7/7/06, David Jencks <[EMAIL PROTECTED]> wrote: I think this will have an extremely debilitating and discouraging effect on everyone involved: no one can commit their own code. Yes, it doesn't sound very entertaining. I'll have to think about it again. "No code ownership" is fine, but IMO everyone likes to commit their own work and say to themselves "I did it". You're right again. What I meant was to ensure that a commit won't break others' daily work only because not everything's been committed. It's not that rarely when we couldn't build Geronimo from a fresh checkout. The other effect is that it makes the change known to more than a very few people which increases changes to fix it in case of troubles. I think it will also tend to give the PMC members even more work to do, which they already don't have time for, and is likely to widen the divide between committers and PMC members. It will also be IMO rather confusing: despite review by 3 PMC members I expect the changes will still be best understood by their author, and if the author is NEVER the committer, it will be nearly impossible to find out who was responsible. That's what I thought we want to avoid, i.e. that a change is best understood by its author. That's what makes that some areas are not handled very well and only when Dave J. is involved a fix might be prepared. Re more work for PMCers, it's not quite true - we've already got more work than it's necessary before RTC and only PMCers' votes are binding so we have to do it anyway. When one claims a change has been tested and +1'ed eventually, it means that the process of applying the change has already been done so the additional step would be to execute 'svn ci'. What additional work are we talking about - svn ci? Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: [RTC] Vote on GERONIMO-2161 - restart 1
On 7/7/06, Jeff Genender <[EMAIL PROTECTED]> wrote: Hey Jacek, BTW, I apologize about the blessing of the final 3 +1s within the 18 hours period. I did not mean to go against your statement. I just recalled an email about 3 +1s allowed it to happen and there was no need to wait...that a -1 could be waged at anytime in the future. If I stepped over the line here, then my complete apologies. I think I may be trying to feel my way through this as well...and I may bump into a wall every now and then. It was my fault and am very glad you've stepped in and help me to understand my mistake. Thanks, Jeff! (I have never thought I'd be so happy after having been pointed out I was wrong ;-)) Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: [RTC] Vote on GERONIMO-2161 - restart 1
On 7/7/06, Jacek Laskowski <[EMAIL PROTECTED]> wrote: On 7/7/06, David Jencks <[EMAIL PROTECTED]> wrote: > My point of view is that while there might be a minimum time needed > in total for a vote, there is no need to wait after the 3rd +1 as > long as that minumum time since the start of the vote has elapsed. > This vote has been going on with additions for 5 days now with no > technical objections, although jason has enhanced the patch in > several ways. Anyone with the slightest concerns about this patch > has had more than adequate time to object, and they continue to be > able to object till the heat death of the universe. I disagree. If it's required new voting, it has to end at the 24-hour period finish. In other scenarios, you're right (and that's why I wrote about the 18-hour time period since Matt begun the vote 6 hours ago). I don't know why I claimed the 24-hour period was required. I appologize for it, Dave. I'm really, really sorry and appreciate your patience. Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: [RTC] Vote on GERONIMO-2161 - restart 1
On 7/7/06, Kevan Miller <[EMAIL PROTECTED]> wrote: I'd rather not troll back through the postings, but I certainly recall that the same guidelines -- there wasn't a minimum time period for an RTC vote. Once you have 3 +1's you would be able to commit and there can still be a -1 at any time (hopefully with some statute of limitation) that will force the commit to be reverted. I think this process works. I'd also expect that a -1 would be preceded by a healthy discussion berore the -1... Yes, you're right. I was mistaken. Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: [RTC] Vote on GERONIMO-2161 - restart 1
On Jul 7, 2006, at 8:40 AM, Jeff Genender wrote: Hey Jacek, BTW, I apologize about the blessing of the final 3 +1s within the 18 hours period. I did not mean to go against your statement. I just recalled an email about 3 +1s allowed it to happen and there was no need to wait...that a -1 could be waged at anytime in the future. If I stepped over the line here, then my complete apologies. I think I may be trying to feel my way through this as well...and I may bump into a wall every now and then. I'd rather not troll back through the postings, but I certainly recall that the same guidelines -- there wasn't a minimum time period for an RTC vote. Once you have 3 +1's you would be able to commit and there can still be a -1 at any time (hopefully with some statute of limitation) that will force the commit to be reverted. I think this process works. I'd also expect that a -1 would be preceded by a healthy discussion berore the -1... --kevan Jeff Jacek Laskowski wrote: On 7/7/06, Jason Dillon <[EMAIL PROTECTED]> wrote: This is applied. :-) Took longer than expected because I happened to switch to a terminal that was set to use JDK 1.5 and I did not realize it... until a few hours later after I was pulling my hair out wondering why the patch god hates me so much. It's because it needs a solution as I think you won't be alone in your pain of applying patches/changes that are incompatible with the unix patch command. I think it would be much better if the person who makes a change is not the one who commits it to trunk, but the last PMCer who voted for it. And a branch the change is built from is established. The solution has such a good effect that the person who works on changes don't have to worry about the commit date until it's rejected when (s)he or anyone else will fix it and a vote starts over (with 24-hour time period). Another good effect is that knowing the revisions a change that's being voted, one can continue his/her work without worrying about disrupting the vote process as the revisions are still in the branch. Phew, I do like the idea! ;-) WDYT? --jason Jacek
Re: [RTC] Vote on GERONIMO-2161 - restart 1
Hey Jacek, BTW, I apologize about the blessing of the final 3 +1s within the 18 hours period. I did not mean to go against your statement. I just recalled an email about 3 +1s allowed it to happen and there was no need to wait...that a -1 could be waged at anytime in the future. If I stepped over the line here, then my complete apologies. I think I may be trying to feel my way through this as well...and I may bump into a wall every now and then. Jeff Jacek Laskowski wrote: > On 7/7/06, Jason Dillon <[EMAIL PROTECTED]> wrote: >> This is applied. >> >> :-) >> >> Took longer than expected because I happened to switch to a terminal >> that was set to use JDK 1.5 and I did not realize it... until a few >> hours later after I was pulling my hair out wondering why the patch >> god hates me so much. > > It's because it needs a solution as I think you won't be alone in your > pain of applying patches/changes that are incompatible with the unix > patch command. > > I think it would be much better if the person who makes a change is > not the one who commits it to trunk, but the last PMCer who voted for > it. And a branch the change is built from is established. The solution > has such a good effect that the person who works on changes don't have > to worry about the commit date until it's rejected when (s)he or > anyone else will fix it and a vote starts over (with 24-hour time > period). Another good effect is that knowing the revisions a change > that's being voted, one can continue his/her work without worrying > about disrupting the vote process as the revisions are still in the > branch. Phew, I do like the idea! ;-) > > WDYT? > >> --jason > > Jacek >
Re: [RTC] Vote on GERONIMO-2161 - restart 1
On Jul 6, 2006, at 11:54 PM, Jacek Laskowski wrote: On 7/7/06, Jason Dillon <[EMAIL PROTECTED]> wrote: This is applied. :-) Took longer than expected because I happened to switch to a terminal that was set to use JDK 1.5 and I did not realize it... until a few hours later after I was pulling my hair out wondering why the patch god hates me so much. It's because it needs a solution as I think you won't be alone in your pain of applying patches/changes that are incompatible with the unix patch command. I think it would be much better if the person who makes a change is not the one who commits it to trunk, but the last PMCer who voted for it. And a branch the change is built from is established. The solution has such a good effect that the person who works on changes don't have to worry about the commit date until it's rejected when (s)he or anyone else will fix it and a vote starts over (with 24-hour time period). Another good effect is that knowing the revisions a change that's being voted, one can continue his/her work without worrying about disrupting the vote process as the revisions are still in the branch. Phew, I do like the idea! ;-) WDYT? I think this will have an extremely debilitating and discouraging effect on everyone involved: no one can commit their own code. "No code ownership" is fine, but IMO everyone likes to commit their own work and say to themselves "I did it". I think it will also tend to give the PMC members even more work to do, which they already don't have time for, and is likely to widen the divide between committers and PMC members. It will also be IMO rather confusing: despite review by 3 PMC members I expect the changes will still be best understood by their author, and if the author is NEVER the committer, it will be nearly impossible to find out who was responsible. non-binding david jencks --jason Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: [RTC] Vote on GERONIMO-2161 - restart 1
I do not believe that your suggestion to have the final voter commit patches will improve collaboration. I see that by adding another layer of process only adds to the chances that the overall process will fail... and IMO taking too long is a failure. I am open to ideas about how to improve how we work with RTC, but I don't see that your suggestion would be beneficial enough to warrant the additional overhead to manage the process. --jason On Jul 7, 2006, at 1:00 AM, Jacek Laskowski wrote: On 7/7/06, Jason Dillon <[EMAIL PROTECTED]> wrote: -1 to this and any other way ways to slow down progress. We need to find more effective ways to work with RTC, not more ways to put up road blocks. -1 requires more than just a thought or doubt. I don't see how it could slow down a process more than it is now? What's wrong with it? I see only positives no negatives wrt the 'branch' plan. Quoting your words (slightly changed): our committer base is too low to compete in the market and any way to improve it is worth to consider. To be honest, I'm going to -1 any other change that doesn't apply gently and can be tested on a fresh, clean local Geronimo sources copy. It will cost us more time to cut better changes and me to help with their preparation and testing, but will do it if necessary - in the name of improving our collaboration. Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: [RTC] Vote on GERONIMO-2161 - restart 1
On 7/7/06, Jason Dillon <[EMAIL PROTECTED]> wrote: -1 to this and any other way ways to slow down progress. We need to find more effective ways to work with RTC, not more ways to put up road blocks. -1 requires more than just a thought or doubt. I don't see how it could slow down a process more than it is now? What's wrong with it? I see only positives no negatives wrt the 'branch' plan. Quoting your words (slightly changed): our committer base is too low to compete in the market and any way to improve it is worth to consider. To be honest, I'm going to -1 any other change that doesn't apply gently and can be tested on a fresh, clean local Geronimo sources copy. It will cost us more time to cut better changes and me to help with their preparation and testing, but will do it if necessary - in the name of improving our collaboration. Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: [RTC] Vote on GERONIMO-2161 - restart 1
I think it would be much better if the person who makes a change is not the one who commits it to trunk, but the last PMCer who voted for it. And a branch the change is built from is established. The solution has such a good effect that the person who works on changes don't have to worry about the commit date until it's rejected when (s)he or anyone else will fix it and a vote starts over (with 24-hour time period). Another good effect is that knowing the revisions a change that's being voted, one can continue his/her work without worrying about disrupting the vote process as the revisions are still in the branch. Phew, I do like the idea! ;-) WDYT? IMO... way to much process. -1 to this and any other way ways to slow down progress. We need to find more effective ways to work with RTC, not more ways to put up road blocks. --jason
Re: [RTC] Vote on GERONIMO-2161 - restart 1
On 7/7/06, Jason Dillon <[EMAIL PROTECTED]> wrote: This is applied. :-) Took longer than expected because I happened to switch to a terminal that was set to use JDK 1.5 and I did not realize it... until a few hours later after I was pulling my hair out wondering why the patch god hates me so much. It's because it needs a solution as I think you won't be alone in your pain of applying patches/changes that are incompatible with the unix patch command. I think it would be much better if the person who makes a change is not the one who commits it to trunk, but the last PMCer who voted for it. And a branch the change is built from is established. The solution has such a good effect that the person who works on changes don't have to worry about the commit date until it's rejected when (s)he or anyone else will fix it and a vote starts over (with 24-hour time period). Another good effect is that knowing the revisions a change that's being voted, one can continue his/her work without worrying about disrupting the vote process as the revisions are still in the branch. Phew, I do like the idea! ;-) WDYT? --jason Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: [RTC] Vote on GERONIMO-2161 - restart 1
On 7/7/06, David Jencks <[EMAIL PROTECTED]> wrote: My point of view is that while there might be a minimum time needed in total for a vote, there is no need to wait after the 3rd +1 as long as that minumum time since the start of the vote has elapsed. This vote has been going on with additions for 5 days now with no technical objections, although jason has enhanced the patch in several ways. Anyone with the slightest concerns about this patch has had more than adequate time to object, and they continue to be able to object till the heat death of the universe. I disagree. If it's required new voting, it has to end at the 24-hour period finish. In other scenarios, you're right (and that's why I wrote about the 18-hour time period since Matt begun the vote 6 hours ago). david jencks Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: [RTC] Vote on GERONIMO-2161 - restart 1
This is applied. :-) Took longer than expected because I happened to switch to a terminal that was set to use JDK 1.5 and I did not realize it... until a few hours later after I was pulling my hair out wondering why the patch god hates me so much. --jason On Jul 6, 2006, at 4:54 PM, Jeff Genender wrote: Consider it blessed. ;-) Jason Dillon wrote: On Jul 6, 2006, at 4:23 PM, David Jencks wrote: My point of view is that while there might be a minimum time needed in total for a vote, there is no need to wait after the 3rd +1 as long as that minumum time since the start of the vote has elapsed. This vote has been going on with additions for 5 days now with no technical objections, although jason has enhanced the patch in several ways. Anyone with the slightest concerns about this patch has had more than adequate time to object, and they continue to be able to object till the heat death of the universe. Commit it now. (non binding) I'd be more than happy to do so if someone from the PMC would bless that action. --jason
Re: [RTC] Vote on GERONIMO-2161 - restart 1
w00t! --jason On Jul 6, 2006, at 4:54 PM, Jeff Genender wrote: Consider it blessed. ;-) Jason Dillon wrote: On Jul 6, 2006, at 4:23 PM, David Jencks wrote: My point of view is that while there might be a minimum time needed in total for a vote, there is no need to wait after the 3rd +1 as long as that minumum time since the start of the vote has elapsed. This vote has been going on with additions for 5 days now with no technical objections, although jason has enhanced the patch in several ways. Anyone with the slightest concerns about this patch has had more than adequate time to object, and they continue to be able to object till the heat death of the universe. Commit it now. (non binding) I'd be more than happy to do so if someone from the PMC would bless that action. --jason
Re: [RTC] Vote on GERONIMO-2161 - restart 1
Consider it blessed. ;-) Jason Dillon wrote: > On Jul 6, 2006, at 4:23 PM, David Jencks wrote: >> My point of view is that while there might be a minimum time needed in >> total for a vote, there is no need to wait after the 3rd +1 as long as >> that minumum time since the start of the vote has elapsed. This vote >> has been going on with additions for 5 days now with no technical >> objections, although jason has enhanced the patch in several ways. >> Anyone with the slightest concerns about this patch has had more than >> adequate time to object, and they continue to be able to object till >> the heat death of the universe. >> >> Commit it now. (non binding) > > I'd be more than happy to do so if someone from the PMC would bless that > action. > > --jason
Re: [RTC] Vote on GERONIMO-2161 - restart 1
On Jul 6, 2006, at 4:23 PM, David Jencks wrote: My point of view is that while there might be a minimum time needed in total for a vote, there is no need to wait after the 3rd +1 as long as that minumum time since the start of the vote has elapsed. This vote has been going on with additions for 5 days now with no technical objections, although jason has enhanced the patch in several ways. Anyone with the slightest concerns about this patch has had more than adequate time to object, and they continue to be able to object till the heat death of the universe. Commit it now. (non binding) I'd be more than happy to do so if someone from the PMC would bless that action. --jason
Re: [RTC] Vote on GERONIMO-2161 - restart 1
On Jul 6, 2006, at 2:09 PM, Jason Dillon wrote: I don't recall Jacek +1'ing... before or after the restart. * * * But, I was more curious how long after the next +1 comes in I should wait before applying this? My point of view is that while there might be a minimum time needed in total for a vote, there is no need to wait after the 3rd +1 as long as that minumum time since the start of the vote has elapsed. This vote has been going on with additions for 5 days now with no technical objections, although jason has enhanced the patch in several ways. Anyone with the slightest concerns about this patch has had more than adequate time to object, and they continue to be able to object till the heat death of the universe. Commit it now. (non binding) david jencks --jason On Jul 6, 2006, at 2:08 PM, Jeff Genender wrote: If Jacek +1d it (I don't recall if he did) you have 3 +1s. Jeff Jason Dillon wrote: IIUC, after this restart, we need one more +1 from a PMC member to allow these changes to be committed to the trunk. Assuming that another +1 comes in soonish, how long shall I wait before applying? --jason On Jul 6, 2006, at 6:57 AM, Matt Hogstrom wrote: +1 to getting this patch in... I spent some time working with Jason and Jacek last night on this patch. It is fairly large and reaching. There appears to be an issue with SVN creating a bad patch file for several files but I don't believe this is Jason's issue but rather with SVN. There are 5 failed hunks in the v5 patch. I manually copied the files from branches/m2migration into trunk as these were the source of the modification. The build was successful and I understand what Jason is doing here. I am giving this patch a +1 and would like to see Jason get this applied at his earliest convenience. There are issues with moving forward but getting on a better code base will accelerate progress on getting to a fully integrated build. We need to understand why SVN is creating bad patches but this shouldn't hold up the migration to M2 effort. This is not an issue with the current patch but a problem with SVN we need to undestand. I would like to see Jason get these changes into trunk as well as resolve the patch issue. Matt *** Notations of applicability *** Here is the output from the patch when I applied it. I increased the FUZZ factor to a horrible 8 but it had no effect. hogstrom:~/dev/geronimo/trunk hogstrom$ patch -p0 -l < ~/Downloads/GERONIMO-2161-v5.patch.txt patching file applications/ldap-realm-demo/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/console/console-standard/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/console/console-ear/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/console/console-core/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/console/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/console/console-framework/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/magicGball/magicGball-ejb/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/magicGball/magicGball-ear/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/magicGball/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/magicGball/magicGball-web/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/magicGball/magicGball-client/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/demo/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/remote-deploy/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/uddi-db/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/uddi-server/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/welcome/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file configs/unavailable-client-deployer/pom.xml patching file configs/welcome-tomcat/pom.xml patching file configs/client-security/pom.xml patching file configs/javamail/pom.xml patching file configs/console-tomcat/pom.xml Hunk #1 succeeded at 16 with fuzz 3. patching file configs/tomcat/pom.xml patching file configs/j2ee-server/pom.xml patching file configs/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file configs/activemq-broker/pom.xml Hunk #1 succeeded at 16 with fuzz 3. patching file configs/jsp-examples-tomcat/pom.xml patching file configs/sharedlib/pom.xml patching file configs/jetty/pom.xml patching file configs/console-jetty/pom.xml patching file configs/client-system/pom.xml patching file configs/unavailable-ejb-deployer/pom.xml patching file configs/openejb-deployer/pom.xml patching file configs/directory/pom.xml patching file configs/jsp-examples-jetty/pom.xml patching file configs/online-deployer/pom.xml patching fil
Re: [RTC] Vote on GERONIMO-2161 - restart 1
On 7/6/06, Jason Dillon <[EMAIL PROTECTED]> wrote: IIUC, after this restart, we need one more +1 from a PMC member to allow these changes to be committed to the trunk. Assuming that another +1 comes in soonish, how long shall I wait before applying? +1 (I did review it only as I had troubles test it out thorougly) Wait 18 hours and go ahead. 18 hours will let the sun round the globe so others get a chance to vote...against ;-) --jason Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: [RTC] Vote on GERONIMO-2161 - restart 1
I don't recall Jacek +1'ing... before or after the restart. * * * But, I was more curious how long after the next +1 comes in I should wait before applying this? --jason On Jul 6, 2006, at 2:08 PM, Jeff Genender wrote: If Jacek +1d it (I don't recall if he did) you have 3 +1s. Jeff Jason Dillon wrote: IIUC, after this restart, we need one more +1 from a PMC member to allow these changes to be committed to the trunk. Assuming that another +1 comes in soonish, how long shall I wait before applying? --jason On Jul 6, 2006, at 6:57 AM, Matt Hogstrom wrote: +1 to getting this patch in... I spent some time working with Jason and Jacek last night on this patch. It is fairly large and reaching. There appears to be an issue with SVN creating a bad patch file for several files but I don't believe this is Jason's issue but rather with SVN. There are 5 failed hunks in the v5 patch. I manually copied the files from branches/m2migration into trunk as these were the source of the modification. The build was successful and I understand what Jason is doing here. I am giving this patch a +1 and would like to see Jason get this applied at his earliest convenience. There are issues with moving forward but getting on a better code base will accelerate progress on getting to a fully integrated build. We need to understand why SVN is creating bad patches but this shouldn't hold up the migration to M2 effort. This is not an issue with the current patch but a problem with SVN we need to undestand. I would like to see Jason get these changes into trunk as well as resolve the patch issue. Matt *** Notations of applicability *** Here is the output from the patch when I applied it. I increased the FUZZ factor to a horrible 8 but it had no effect. hogstrom:~/dev/geronimo/trunk hogstrom$ patch -p0 -l < ~/Downloads/GERONIMO-2161-v5.patch.txt patching file applications/ldap-realm-demo/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/console/console-standard/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/console/console-ear/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/console/console-core/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/console/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/console/console-framework/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/magicGball/magicGball-ejb/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/magicGball/magicGball-ear/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/magicGball/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/magicGball/magicGball-web/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/magicGball/magicGball-client/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/demo/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/remote-deploy/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/uddi-db/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/uddi-server/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/welcome/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file configs/unavailable-client-deployer/pom.xml patching file configs/welcome-tomcat/pom.xml patching file configs/client-security/pom.xml patching file configs/javamail/pom.xml patching file configs/console-tomcat/pom.xml Hunk #1 succeeded at 16 with fuzz 3. patching file configs/tomcat/pom.xml patching file configs/j2ee-server/pom.xml patching file configs/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file configs/activemq-broker/pom.xml Hunk #1 succeeded at 16 with fuzz 3. patching file configs/jsp-examples-tomcat/pom.xml patching file configs/sharedlib/pom.xml patching file configs/jetty/pom.xml patching file configs/console-jetty/pom.xml patching file configs/client-system/pom.xml patching file configs/unavailable-ejb-deployer/pom.xml patching file configs/openejb-deployer/pom.xml patching file configs/directory/pom.xml patching file configs/jsp-examples-jetty/pom.xml patching file configs/online-deployer/pom.xml patching file configs/j2ee-deployer/pom.xml patching file configs/tomcat-deployer/pom.xml patching file configs/activemq/pom.xml Hunk #1 succeeded at 16 with fuzz 3. patching file configs/geronimo-gbean-deployer/pom.xml patching file configs/shutdown/pom.xml patching file configs/hot-deployer/pom.xml patching file configs/servlets-examples-jetty/pom.xml patching file configs/jetty-deployer/pom.xml patching file configs/openejb/pom.xml patching file configs/unavailable-webservices-deployer/pom.xml patching file configs/axis-deployer/pom.xml patching file configs/system-database/pom.xml patching file configs/ldap-demo-tomcat/pom.xml pat
Re: [RTC] Vote on GERONIMO-2161 - restart 1
If Jacek +1d it (I don't recall if he did) you have 3 +1s. Jeff Jason Dillon wrote: > IIUC, after this restart, we need one more +1 from a PMC member to allow > these changes to be committed to the trunk. > > Assuming that another +1 comes in soonish, how long shall I wait before > applying? > > --jason > > > On Jul 6, 2006, at 6:57 AM, Matt Hogstrom wrote: > >> +1 to getting this patch in... >> >> I spent some time working with Jason and Jacek last night on this >> patch. It is fairly large and reaching. There appears to be an issue >> with SVN creating a bad patch file for several files but I don't >> believe this is Jason's issue but rather with SVN. >> >> There are 5 failed hunks in the v5 patch. I manually copied the files >> from branches/m2migration into trunk as these were the source of the >> modification. The build was successful and I understand what Jason is >> doing here. >> >> I am giving this patch a +1 and would like to see Jason get this >> applied at his earliest convenience. >> >> There are issues with moving forward but getting on a better code base >> will accelerate progress on getting to a fully integrated build. >> >> We need to understand why SVN is creating bad patches but this >> shouldn't hold up the migration to M2 effort. This is not an issue >> with the current patch but a problem with SVN we need to undestand. >> >> I would like to see Jason get these changes into trunk as well as >> resolve the patch issue. >> >> >> Matt >> >> *** Notations of applicability *** >> >> Here is the output from the patch when I applied it. I increased the >> FUZZ factor to a horrible 8 but it had no effect. >> >> >> hogstrom:~/dev/geronimo/trunk hogstrom$ patch -p0 -l < >> ~/Downloads/GERONIMO-2161-v5.patch.txt >> patching file applications/ldap-realm-demo/pom.xml >> Hunk #1 succeeded at 17 with fuzz 2. >> patching file applications/console/console-standard/pom.xml >> Hunk #1 succeeded at 17 with fuzz 2. >> patching file applications/console/console-ear/pom.xml >> Hunk #1 succeeded at 17 with fuzz 2. >> patching file applications/console/console-core/pom.xml >> Hunk #1 succeeded at 17 with fuzz 2. >> patching file applications/console/pom.xml >> Hunk #1 succeeded at 17 with fuzz 2. >> patching file applications/console/console-framework/pom.xml >> Hunk #1 succeeded at 17 with fuzz 2. >> patching file applications/magicGball/magicGball-ejb/pom.xml >> Hunk #1 succeeded at 17 with fuzz 2. >> patching file applications/magicGball/magicGball-ear/pom.xml >> Hunk #1 succeeded at 17 with fuzz 2. >> patching file applications/magicGball/pom.xml >> Hunk #1 succeeded at 17 with fuzz 2. >> patching file applications/magicGball/magicGball-web/pom.xml >> Hunk #1 succeeded at 17 with fuzz 2. >> patching file applications/magicGball/magicGball-client/pom.xml >> Hunk #1 succeeded at 17 with fuzz 2. >> patching file applications/demo/pom.xml >> Hunk #1 succeeded at 17 with fuzz 2. >> patching file applications/remote-deploy/pom.xml >> Hunk #1 succeeded at 17 with fuzz 2. >> patching file applications/uddi-db/pom.xml >> Hunk #1 succeeded at 17 with fuzz 2. >> patching file applications/uddi-server/pom.xml >> Hunk #1 succeeded at 17 with fuzz 2. >> patching file applications/pom.xml >> Hunk #1 succeeded at 17 with fuzz 2. >> patching file applications/welcome/pom.xml >> Hunk #1 succeeded at 17 with fuzz 2. >> patching file configs/unavailable-client-deployer/pom.xml >> patching file configs/welcome-tomcat/pom.xml >> patching file configs/client-security/pom.xml >> patching file configs/javamail/pom.xml >> patching file configs/console-tomcat/pom.xml >> Hunk #1 succeeded at 16 with fuzz 3. >> patching file configs/tomcat/pom.xml >> patching file configs/j2ee-server/pom.xml >> patching file configs/pom.xml >> Hunk #1 succeeded at 17 with fuzz 2. >> patching file configs/activemq-broker/pom.xml >> Hunk #1 succeeded at 16 with fuzz 3. >> patching file configs/jsp-examples-tomcat/pom.xml >> patching file configs/sharedlib/pom.xml >> patching file configs/jetty/pom.xml >> patching file configs/console-jetty/pom.xml >> patching file configs/client-system/pom.xml >> patching file configs/unavailable-ejb-deployer/pom.xml >> patching file configs/openejb-deployer/pom.xml >> patching file configs/directory/pom.xml >> patching file configs/jsp-examples-jetty/pom.xml >> patching file configs/online-deployer/pom.xml >> patching file configs/j2ee-deployer/pom.xml >> patching file configs/tomcat-deployer/pom.xml >> patching file configs/activemq/pom.xml >> Hunk #1 succeeded at 16 with fuzz 3. >> patching file configs/geronimo-gbean-deployer/pom.xml >> patching file configs/shutdown/pom.xml >> patching file configs/hot-deployer/pom.xml >> patching file configs/servlets-examples-jetty/pom.xml >> patching file configs/jetty-deployer/pom.xml >> patching file configs/openejb/pom.xml >> patching file configs/unavailable-webservices-deployer/pom.xml >> patching file configs/axis-deployer/pom.xml >> patching file configs/sy
Re: [RTC] Vote on GERONIMO-2161 - restart 1
IIUC, after this restart, we need one more +1 from a PMC member to allow these changes to be committed to the trunk. Assuming that another +1 comes in soonish, how long shall I wait before applying? --jason On Jul 6, 2006, at 6:57 AM, Matt Hogstrom wrote: +1 to getting this patch in... I spent some time working with Jason and Jacek last night on this patch. It is fairly large and reaching. There appears to be an issue with SVN creating a bad patch file for several files but I don't believe this is Jason's issue but rather with SVN. There are 5 failed hunks in the v5 patch. I manually copied the files from branches/m2migration into trunk as these were the source of the modification. The build was successful and I understand what Jason is doing here. I am giving this patch a +1 and would like to see Jason get this applied at his earliest convenience. There are issues with moving forward but getting on a better code base will accelerate progress on getting to a fully integrated build. We need to understand why SVN is creating bad patches but this shouldn't hold up the migration to M2 effort. This is not an issue with the current patch but a problem with SVN we need to undestand. I would like to see Jason get these changes into trunk as well as resolve the patch issue. Matt *** Notations of applicability *** Here is the output from the patch when I applied it. I increased the FUZZ factor to a horrible 8 but it had no effect. hogstrom:~/dev/geronimo/trunk hogstrom$ patch -p0 -l < ~/Downloads/ GERONIMO-2161-v5.patch.txt patching file applications/ldap-realm-demo/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/console/console-standard/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/console/console-ear/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/console/console-core/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/console/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/console/console-framework/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/magicGball/magicGball-ejb/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/magicGball/magicGball-ear/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/magicGball/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/magicGball/magicGball-web/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/magicGball/magicGball-client/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/demo/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/remote-deploy/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/uddi-db/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/uddi-server/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/welcome/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file configs/unavailable-client-deployer/pom.xml patching file configs/welcome-tomcat/pom.xml patching file configs/client-security/pom.xml patching file configs/javamail/pom.xml patching file configs/console-tomcat/pom.xml Hunk #1 succeeded at 16 with fuzz 3. patching file configs/tomcat/pom.xml patching file configs/j2ee-server/pom.xml patching file configs/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file configs/activemq-broker/pom.xml Hunk #1 succeeded at 16 with fuzz 3. patching file configs/jsp-examples-tomcat/pom.xml patching file configs/sharedlib/pom.xml patching file configs/jetty/pom.xml patching file configs/console-jetty/pom.xml patching file configs/client-system/pom.xml patching file configs/unavailable-ejb-deployer/pom.xml patching file configs/openejb-deployer/pom.xml patching file configs/directory/pom.xml patching file configs/jsp-examples-jetty/pom.xml patching file configs/online-deployer/pom.xml patching file configs/j2ee-deployer/pom.xml patching file configs/tomcat-deployer/pom.xml patching file configs/activemq/pom.xml Hunk #1 succeeded at 16 with fuzz 3. patching file configs/geronimo-gbean-deployer/pom.xml patching file configs/shutdown/pom.xml patching file configs/hot-deployer/pom.xml patching file configs/servlets-examples-jetty/pom.xml patching file configs/jetty-deployer/pom.xml patching file configs/openejb/pom.xml patching file configs/unavailable-webservices-deployer/pom.xml patching file configs/axis-deployer/pom.xml patching file configs/system-database/pom.xml patching file configs/ldap-demo-tomcat/pom.xml patching file configs/upgrade/pom.xml patching file configs/welcome-jetty/pom.xml patching file configs/j2ee-security/pom.xml patching file configs/upgrade-cli/pom.xml patching file configs/rmi-naming/pom.xml patching file configs/ldap-demo-jetty/pom.xml patching file configs/client-deployer/pom.xml
Re: [RTC] Vote on GERONIMO-2161 - restart 1
On 7/6/06, Jason Dillon <[EMAIL PROTECTED]> wrote: On Jul 6, 2006, at 9:13 AM, Jacek Laskowski wrote: > I wonder how the changes will be applied to trunk if patch doesn't > work? It is easy enough to apply the patch and then copy the files from the svkmerge/m2migration branch manually to recreate the complete v5 patch changes. I must be missing something as I don't understand how you can use 'easy enough' when we all were struggling with applying it. Could you elaborate a bit more? --jason Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: [RTC] Vote on GERONIMO-2161 - restart 1
On Jul 6, 2006, at 9:13 AM, Jacek Laskowski wrote: On 7/6/06, Matt Hogstrom <[EMAIL PROTECTED]> wrote: We need to understand why SVN is creating bad patches but this shouldn't hold up the migration to M2 effort. This is not an issue with the current patch but a problem with SVN we need to undestand. Don't we have it behind us already? I thought we agreed upon the fact that unix patch is incompatible with svn diff and thus we need to use svn diff to create a patch for review and merge it to our own local copies using svn merge. The point is to get the revisions a patch is built from, but the rest should work. We must resolve why svn diff + patch does not work... else it will be very, very difficult to take in changes from non-commiters who do not have access to create branches for us to merge. To be honest, I don't like how the patch has been reviewed and voted. How can we say it works if we (me, including) couldn't apply it to our local source copies? If one's going to say it's because of the unix patch I'll start screaming...That's why svn merge exists, doesn't it? Ok, stop whining... Dude! You can apply the changes to your workspace... many other have done so. Yes, patch barfs on a few bits, but copy over the changed files, which are all minor anyways, and you are set. --jason
Re: [RTC] Vote on GERONIMO-2161 - restart 1
On Jul 6, 2006, at 9:13 AM, Jacek Laskowski wrote: I wonder how the changes will be applied to trunk if patch doesn't work? It is easy enough to apply the patch and then copy the files from the svkmerge/m2migration branch manually to recreate the complete v5 patch changes. --jason
Re: [RTC] Vote on GERONIMO-2161 - restart 1
Jacek, I agree that that it has been hard to install. We need to figure out why. That is another issue I think. Matt Jacek Laskowski wrote: On 7/6/06, Matt Hogstrom <[EMAIL PROTECTED]> wrote: We need to understand why SVN is creating bad patches but this shouldn't hold up the migration to M2 effort. This is not an issue with the current patch but a problem with SVN we need to undestand. Don't we have it behind us already? I thought we agreed upon the fact that unix patch is incompatible with svn diff and thus we need to use svn diff to create a patch for review and merge it to our own local copies using svn merge. The point is to get the revisions a patch is built from, but the rest should work. I would like to see Jason get these changes into trunk as well as resolve the patch issue. (Oh, poor Jacek and his poor English that doesn't let him explain how we should proceed :-)) To be honest, I don't like how the patch has been reviewed and voted. How can we say it works if we (me, including) couldn't apply it to our local source copies? If one's going to say it's because of the unix patch I'll start screaming...That's why svn merge exists, doesn't it? Ok, stop whining... I wonder how the changes will be applied to trunk if patch doesn't work? Jacek
Re: [RTC] Vote on GERONIMO-2161 - restart 1
On 7/6/06, Matt Hogstrom <[EMAIL PROTECTED]> wrote: We need to understand why SVN is creating bad patches but this shouldn't hold up the migration to M2 effort. This is not an issue with the current patch but a problem with SVN we need to undestand. Don't we have it behind us already? I thought we agreed upon the fact that unix patch is incompatible with svn diff and thus we need to use svn diff to create a patch for review and merge it to our own local copies using svn merge. The point is to get the revisions a patch is built from, but the rest should work. I would like to see Jason get these changes into trunk as well as resolve the patch issue. (Oh, poor Jacek and his poor English that doesn't let him explain how we should proceed :-)) To be honest, I don't like how the patch has been reviewed and voted. How can we say it works if we (me, including) couldn't apply it to our local source copies? If one's going to say it's because of the unix patch I'll start screaming...That's why svn merge exists, doesn't it? Ok, stop whining... I wonder how the changes will be applied to trunk if patch doesn't work? Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: [RTC] Vote on GERONIMO-2161 - restart 1
I get similar issues, but upon carefully reviewing the patch(es), I am in full agreement. +1 to the patch. Jeff Matt Hogstrom wrote: > +1 to getting this patch in... > > I spent some time working with Jason and Jacek last night on this > patch. It is fairly large and reaching. There appears to be an issue > with SVN creating a bad patch file for several files but I don't believe > this is Jason's issue but rather with SVN. > > There are 5 failed hunks in the v5 patch. I manually copied the files > from branches/m2migration into trunk as these were the source of the > modification. The build was successful and I understand what Jason is > doing here. > > I am giving this patch a +1 and would like to see Jason get this applied > at his earliest convenience. > > There are issues with moving forward but getting on a better code base > will accelerate progress on getting to a fully integrated build. > > We need to understand why SVN is creating bad patches but this shouldn't > hold up the migration to M2 effort. This is not an issue with the > current patch but a problem with SVN we need to undestand. > > I would like to see Jason get these changes into trunk as well as > resolve the patch issue. > > > Matt > > *** Notations of applicability *** > > Here is the output from the patch when I applied it. I increased the > FUZZ factor to a horrible 8 but it had no effect. > > > hogstrom:~/dev/geronimo/trunk hogstrom$ patch -p0 -l < > ~/Downloads/GERONIMO-2161-v5.patch.txt > patching file applications/ldap-realm-demo/pom.xml > Hunk #1 succeeded at 17 with fuzz 2. > patching file applications/console/console-standard/pom.xml > Hunk #1 succeeded at 17 with fuzz 2. > patching file applications/console/console-ear/pom.xml > Hunk #1 succeeded at 17 with fuzz 2. > patching file applications/console/console-core/pom.xml > Hunk #1 succeeded at 17 with fuzz 2. > patching file applications/console/pom.xml > Hunk #1 succeeded at 17 with fuzz 2. > patching file applications/console/console-framework/pom.xml > Hunk #1 succeeded at 17 with fuzz 2. > patching file applications/magicGball/magicGball-ejb/pom.xml > Hunk #1 succeeded at 17 with fuzz 2. > patching file applications/magicGball/magicGball-ear/pom.xml > Hunk #1 succeeded at 17 with fuzz 2. > patching file applications/magicGball/pom.xml > Hunk #1 succeeded at 17 with fuzz 2. > patching file applications/magicGball/magicGball-web/pom.xml > Hunk #1 succeeded at 17 with fuzz 2. > patching file applications/magicGball/magicGball-client/pom.xml > Hunk #1 succeeded at 17 with fuzz 2. > patching file applications/demo/pom.xml > Hunk #1 succeeded at 17 with fuzz 2. > patching file applications/remote-deploy/pom.xml > Hunk #1 succeeded at 17 with fuzz 2. > patching file applications/uddi-db/pom.xml > Hunk #1 succeeded at 17 with fuzz 2. > patching file applications/uddi-server/pom.xml > Hunk #1 succeeded at 17 with fuzz 2. > patching file applications/pom.xml > Hunk #1 succeeded at 17 with fuzz 2. > patching file applications/welcome/pom.xml > Hunk #1 succeeded at 17 with fuzz 2. > patching file configs/unavailable-client-deployer/pom.xml > patching file configs/welcome-tomcat/pom.xml > patching file configs/client-security/pom.xml > patching file configs/javamail/pom.xml > patching file configs/console-tomcat/pom.xml > Hunk #1 succeeded at 16 with fuzz 3. > patching file configs/tomcat/pom.xml > patching file configs/j2ee-server/pom.xml > patching file configs/pom.xml > Hunk #1 succeeded at 17 with fuzz 2. > patching file configs/activemq-broker/pom.xml > Hunk #1 succeeded at 16 with fuzz 3. > patching file configs/jsp-examples-tomcat/pom.xml > patching file configs/sharedlib/pom.xml > patching file configs/jetty/pom.xml > patching file configs/console-jetty/pom.xml > patching file configs/client-system/pom.xml > patching file configs/unavailable-ejb-deployer/pom.xml > patching file configs/openejb-deployer/pom.xml > patching file configs/directory/pom.xml > patching file configs/jsp-examples-jetty/pom.xml > patching file configs/online-deployer/pom.xml > patching file configs/j2ee-deployer/pom.xml > patching file configs/tomcat-deployer/pom.xml > patching file configs/activemq/pom.xml > Hunk #1 succeeded at 16 with fuzz 3. > patching file configs/geronimo-gbean-deployer/pom.xml > patching file configs/shutdown/pom.xml > patching file configs/hot-deployer/pom.xml > patching file configs/servlets-examples-jetty/pom.xml > patching file configs/jetty-deployer/pom.xml > patching file configs/openejb/pom.xml > patching file configs/unavailable-webservices-deployer/pom.xml > patching file configs/axis-deployer/pom.xml > patching file configs/system-database/pom.xml > patching file configs/ldap-demo-tomcat/pom.xml > patching file configs/upgrade/pom.xml > patching file configs/welcome-jetty/pom.xml > patching file configs/j2ee-security/pom.xml > patching file configs/upgrade-cli/pom.xml > patching file configs/rmi-naming/pom.xml > patching file configs/ldap-demo-jet
[RTC] Vote on GERONIMO-2161 - restart 1
+1 to getting this patch in... I spent some time working with Jason and Jacek last night on this patch. It is fairly large and reaching. There appears to be an issue with SVN creating a bad patch file for several files but I don't believe this is Jason's issue but rather with SVN. There are 5 failed hunks in the v5 patch. I manually copied the files from branches/m2migration into trunk as these were the source of the modification. The build was successful and I understand what Jason is doing here. I am giving this patch a +1 and would like to see Jason get this applied at his earliest convenience. There are issues with moving forward but getting on a better code base will accelerate progress on getting to a fully integrated build. We need to understand why SVN is creating bad patches but this shouldn't hold up the migration to M2 effort. This is not an issue with the current patch but a problem with SVN we need to undestand. I would like to see Jason get these changes into trunk as well as resolve the patch issue. Matt *** Notations of applicability *** Here is the output from the patch when I applied it. I increased the FUZZ factor to a horrible 8 but it had no effect. hogstrom:~/dev/geronimo/trunk hogstrom$ patch -p0 -l < ~/Downloads/GERONIMO-2161-v5.patch.txt patching file applications/ldap-realm-demo/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/console/console-standard/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/console/console-ear/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/console/console-core/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/console/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/console/console-framework/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/magicGball/magicGball-ejb/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/magicGball/magicGball-ear/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/magicGball/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/magicGball/magicGball-web/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/magicGball/magicGball-client/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/demo/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/remote-deploy/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/uddi-db/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/uddi-server/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file applications/welcome/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file configs/unavailable-client-deployer/pom.xml patching file configs/welcome-tomcat/pom.xml patching file configs/client-security/pom.xml patching file configs/javamail/pom.xml patching file configs/console-tomcat/pom.xml Hunk #1 succeeded at 16 with fuzz 3. patching file configs/tomcat/pom.xml patching file configs/j2ee-server/pom.xml patching file configs/pom.xml Hunk #1 succeeded at 17 with fuzz 2. patching file configs/activemq-broker/pom.xml Hunk #1 succeeded at 16 with fuzz 3. patching file configs/jsp-examples-tomcat/pom.xml patching file configs/sharedlib/pom.xml patching file configs/jetty/pom.xml patching file configs/console-jetty/pom.xml patching file configs/client-system/pom.xml patching file configs/unavailable-ejb-deployer/pom.xml patching file configs/openejb-deployer/pom.xml patching file configs/directory/pom.xml patching file configs/jsp-examples-jetty/pom.xml patching file configs/online-deployer/pom.xml patching file configs/j2ee-deployer/pom.xml patching file configs/tomcat-deployer/pom.xml patching file configs/activemq/pom.xml Hunk #1 succeeded at 16 with fuzz 3. patching file configs/geronimo-gbean-deployer/pom.xml patching file configs/shutdown/pom.xml patching file configs/hot-deployer/pom.xml patching file configs/servlets-examples-jetty/pom.xml patching file configs/jetty-deployer/pom.xml patching file configs/openejb/pom.xml patching file configs/unavailable-webservices-deployer/pom.xml patching file configs/axis-deployer/pom.xml patching file configs/system-database/pom.xml patching file configs/ldap-demo-tomcat/pom.xml patching file configs/upgrade/pom.xml patching file configs/welcome-jetty/pom.xml patching file configs/j2ee-security/pom.xml patching file configs/upgrade-cli/pom.xml patching file configs/rmi-naming/pom.xml patching file configs/ldap-demo-jetty/pom.xml patching file configs/client-deployer/pom.xml patching file configs/client-corba/src/plan/plan.xml Hunk #2 succeeded at 17 with fuzz 2. patching file configs/client-corba/pom.xml patching file configs/axis/pom.xml Hunk #1 succeeded at 16 with fuzz 3. patching file configs/j2ee-system/pom.xml patching file configs/servlets-examples
