+1
Hiram Chirino wrote: > +1 > > On 6/13/06, David Jencks <[EMAIL PROTECTED]> wrote: >> This is really a pretty simple minded uncontroversial patch that's >> been sitting around for 3 or 4 days now after 2 quick +1's. I know >> we're trying to get 1.1 out the door but another review would be >> really appreciated to keep the m2 migration moving. >> >> thanks >> david jencks >> >> On Jun 10, 2006, at 10:13 AM, Aaron Mulder wrote: >> >> > I've read through it and support it, but have not tried it. Since I >> > also have mac/linux and trust David J, here's my +1. :) >> > >> > Thanks, >> > Aaron >> > >> > On 6/10/06, David Jencks <[EMAIL PROTECTED]> wrote: >> >> To review, in 1.0 we had problems with web app classloaders that >> >> prevented gbeans being loaded from the web app classloader: as a >> >> workaround for remote-deploy we put the gbean classes for the web app >> >> in remote-deploy-lib. This patch brings everything back into remote- >> >> deploy. >> >> >> >> I've provided instructions for a mac/linux system in the jira issue, >> >> applied the patch, and verified it works in m1 and m2 builds. >> >> >> >> Here's my +1 to committing it. >> >> >> >> thanks >> >> david jencks >> >> >> >> >> >> >> >> On Jun 9, 2006, at 12:52 PM, Prasad Kashyap wrote: >> >> >> >> > Sounds good. As per your comments I have attached instructions >> >> in the >> >> > comments and a patch (remote-deploy-v3.patch) that will also >> >> take into >> >> > account m1 build. >> >> > >> >> > Please review and vote. >> >> > >> >> > Cheers >> >> > Prasad >> >> > >> >> > On 6/9/06, David Jencks <[EMAIL PROTECTED]> wrote: >> >> >> I don't think this is quite ready for a vote yet, and I'm not >> >> >> convinced it requires a vote. >> >> >> >> >> >> First, it really should include more of a description of what the >> >> >> purpose of the change is, such as: >> >> >> >> >> >> "Due to bugs in the web app classloader in 1.0, the remote >> >> deploy war >> >> >> was split into 2 modules. Since that classloader bug has been >> >> >> resolved in 1.1 it's time to merge this stuff back into one >> >> module" >> >> >> >> >> >> Second, when a patch moves a file, it should not be applied as a >> >> >> patch. The patch might be OK to look at, but we have to >> >> preserve svn >> >> >> history, so whoever is going to "apply the patch" needs to know >> >> the >> >> >> svn commands that resulted in the patch. Here we need >> >> something like >> >> >> >> >> >> >> >> >> "Run these svn commands: >> >> >> svn mv modules/remote-deploy-lib/src/java/......java modules/ >> >> remote- >> >> >> deploy/src/java/.... >> >> >> ... >> >> >> svn rm modules/remote-deploy-lib >> >> >> " >> >> >> Other adjustments to make the build work again should be in a >> >> patch >> >> >> that does not include the effects of the svn commands. >> >> >> >> >> >> Thirdly I don't think this patch fixes the m1 build.... >> >> unfortunately >> >> >> we can't throw it out yet. >> >> >> >> >> >> The reason I don't think this requires a vote is that it does not >> >> >> change any java code and is part of the bug fix to the web app >> >> >> classloading. However I think since you proposed a vote and we >> >> >> haven't had much practice voting yet it would be a good idea to go >> >> >> through the vote process on this small uncontroversial change. >> >> >> >> >> >> Many thanks >> >> >> david jencks >> >> >> >> >> >> On Jun 9, 2006, at 9:23 AM, Prasad Kashyap wrote: >> >> >> >> >> >> > Merged remote-deploy-lib with remote-deploy. >> >> >> > Migrated remote-deploy to M2. >> >> >> > >> >> >> > http://issues.apache.org/jira/browse/GERONIMO-2098 >> >> >> >> >> >> >> >> >> >> >> >> > >
