+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
>> >> >>
>> >> >>
>> >>
>> >>
>>
>>
>
>