Return-Path: Delivered-To: apmail-geronimo-dev-archive@www.apache.org Received: (qmail 51931 invoked from network); 8 Mar 2007 12:44:53 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 8 Mar 2007 12:44:53 -0000 Received: (qmail 55148 invoked by uid 500); 8 Mar 2007 12:45:00 -0000 Delivered-To: apmail-geronimo-dev-archive@geronimo.apache.org Received: (qmail 55096 invoked by uid 500); 8 Mar 2007 12:45:00 -0000 Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: Reply-To: dev@geronimo.apache.org List-Id: Delivered-To: mailing list dev@geronimo.apache.org Received: (qmail 55085 invoked by uid 99); 8 Mar 2007 12:45:00 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 08 Mar 2007 04:45:00 -0800 X-ASF-Spam-Status: No, hits=2.0 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (herse.apache.org: domain of midha.rakesh@gmail.com designates 64.233.184.225 as permitted sender) Received: from [64.233.184.225] (HELO wr-out-0506.google.com) (64.233.184.225) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 08 Mar 2007 04:44:50 -0800 Received: by wr-out-0506.google.com with SMTP id 71so779618wri for ; Thu, 08 Mar 2007 04:44:29 -0800 (PST) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=iZG/9XxgQlIhFB7lyAng944Resi4WOBoN3fHdJY9JZPPgXAS8IGaRpqw+fiSCj/nXwDU4rkJNipqJt7oeB287SNuvX2WndMJ+FjtW9vj9RfCupvejSJlTflDRTA9oEkZ5w/i4F9+Vfuj2dLoqUdbFSzN+aHWp0m3v5PILGNk0UM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=oI5dBKlfAQvfu1q/NDkXqt6DA6sixsZVZsIMdwzXdqY0XIma8hc/pEyiK3VaOw9646vwsdP0c5bAhaMuHn2XwWT6Dsi0dgLtN5Gt4YMH2z0UPQKeMEJcnI0M2ierm8vlKugpuCEmtb0a3OJ0TstsINPxm0RCmpXRxn0aEfa0LYM= Received: by 10.100.57.14 with SMTP id f14mr172931ana.1173357869254; Thu, 08 Mar 2007 04:44:29 -0800 (PST) Received: by 10.100.174.7 with HTTP; Thu, 8 Mar 2007 04:44:29 -0800 (PST) Message-ID: <1f52a95c0703080444y19971a5ex1ea73699bc6832a0@mail.gmail.com> Date: Thu, 8 Mar 2007 18:14:29 +0530 From: "Rakesh Midha" To: dev@geronimo.apache.org Subject: Re: ClientCommandLine and Daemon - Changing boot approach? In-Reply-To: <45C586FB-C35F-4047-9100-CA71EDCD125C@optusnet.com.au> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_107126_28148826.1173357869088" References: <3BA0073C-94E2-4C1D-AACA-F0CD78D9B368@optusnet.com.au> <1f52a95c0703070604v332a8184saa63ed5f60a25106@mail.gmail.com> <45C586FB-C35F-4047-9100-CA71EDCD125C@optusnet.com.au> X-Virus-Checked: Checked by ClamAV on apache.org ------=_Part_107126_28148826.1173357869088 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hello Gianny Oh I got it now, I think this sounds great to me. Wait just one more question, how will you use ClientCommandLine, I mean when geronimo-system is not in lib directory, ClientCommandLine class will be available for direct access. Are you sure you can move geronimo-system-2.0-SNAPSHOT.jar out of lib. Thanks Rakesh On 3/8/07, Gianny Damour wrote: > > Hello Rakesh, > > The dependencies which will move out of lib/ are: > backport-util-concurrent-2.2.jar > commons-jexl-1.1.jar > geronimo-common-2.0-SNAPSHOT.jar > geronimo-system-2.0-SNAPSHOT.jar > geronimo-util-2.0-SNAPSHOT.jar > ognl-2.6.9.jar > xstream-1.1.3.jar > > ClientCommandLine and Daemon will still reside in geronimo-system and > they will implement org.apache.geronimo.kernel.util.Main. > > The offline deployer already uses the same approach we are suggesting > to apply to ClientCommandLine and Daemon. And it is not impacted by > the change. > > Thanks, > Gianny > > On 08/03/2007, at 1:04 AM, Rakesh Midha wrote: > > > Hello Gianny > > > > Question? What all dependency will you be able to move out of lib > > using this. > > > > Where will ClientCommandLine and Daemon implenting tje > > MainBootstrapper interface will reside. > > > > I am not sure what all advantages will you be able to get out of > > this redistribution. Also any thoughts on effect it may have on > > offline deployer. > > > > Thanks > > Rakesh > > > > On 3/7/07, Gianny Damour wrote: Hi, > > > > Following the introduction of a potentially simpler bootstrapping > > mechanism (currently used by the deployers), we now have an > > opportunity to refactor ClientCommandLine and Daemon to leverage this > > same approach. > > > > The idea of the new bootstrapping mechanism is as follows: > > MainBootstrapper boots a configuration, gets from the Kernel a Main > > implementation and then delegates to it. As the Main implementation > > class can be loaded from the boot repository, rooted at repository/ > > by default, the executable jar instantiating MainBootstrapper can be > > pretty generic with respect to its Class-Path entries: only geronimo- > > kernel plus its dependencies are needed. > > > > ClientCommandLine and Daemon could be refactored to implement the > > Main interface MainBootstrapper is looking for. With these changes, > > we should be able to move some dependencies from lib/ to repository/ > > and also uniform the way CLIs are working. > > > > Any concerns if I do these changes? > > > > Thanks, > > Gianny > > > > ------=_Part_107126_28148826.1173357869088 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hello Gianny

Oh I got it now, I think this sounds great to me.

Wait just one more question, how will you use ClientCommandLine, I mean when geronimo-system is not in lib directory, ClientCommandLine class will be available for direct access. Are you sure you can move geronimo-system-2.0-SNAPSHOT.jar out of lib.

Thanks
Rakesh

On 3/8/07, Gianny Damour <gianny.damour@optusnet.com.au > wrote:
Hello Rakesh,

The dependencies which will move out of lib/ are:
backport-util-concurrent-2.2.jar
commons-jexl-1.1.jar
geronimo-common-2.0-SNAPSHOT.jar
geronimo-system-2.0-SNAPSHOT.jar
geronimo-util-2.0-SNAPSHOT.jar
ognl-2.6.9.jar
xstream-1.1.3.jar

ClientCommandLine and Daemon will still reside in geronimo-system and
they will implement org.apache.geronimo.kernel.util.Main.

The offline deployer already uses the same approach we are suggesting
to apply to ClientCommandLine and Daemon. And it is not impacted by
the change.

Thanks,
Gianny

On 08/03/2007, at 1:04 AM, Rakesh Midha wrote:

> Hello Gianny
>
> Question? What all dependency will you be able to move out of lib
> using this.
>
> Where will ClientCommandLine and Daemon implenting tje
> MainBootstrapper interface will reside.
>
> I am not sure what all advantages will you be able to get out of
> this redistribution. Also any thoughts on effect it may have on
> offline deployer.
>
> Thanks
> Rakesh
>
> On 3/7/07, Gianny Damour <gianny.damour@optusnet.com.au> wrote: Hi,
>
> Following the introduction of a potentially simpler bootstrapping
> mechanism (currently used by the deployers), we now have an
> opportunity to refactor ClientCommandLine and Daemon to leverage this
> same approach.
>
> The idea of the new bootstrapping mechanism is as follows:
> MainBootstrapper boots a configuration, gets from the Kernel a Main
> implementation and then delegates to it. As the Main implementation
> class can be loaded from the boot repository, rooted at repository/
> by default, the executable jar instantiating MainBootstrapper can be
> pretty generic with respect to its Class-Path entries: only geronimo-
> kernel plus its dependencies are needed.
>
> ClientCommandLine and Daemon could be refactored to implement the
> Main interface MainBootstrapper is looking for. With these changes,
> we should be able to move some dependencies from lib/ to repository/
> and also uniform the way CLIs are working.
>
> Any concerns if I do these changes?
>
> Thanks,
> Gianny
>


------=_Part_107126_28148826.1173357869088--