Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.039
sec
:-)
On 09/03/2007, at 12:01 AM, David Jencks wrote:
This is a test to see if I understand how this will work :-)
I think that ClientCommandLine won't be the java main class any
more, it will be the class implementing o.a.g. ... Main that the
java main class will call after booting a classloader containing
geronimo-system.
thanks
david jencks
On Mar 8, 2007, at 7:44 AM, Rakesh Midha wrote:
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 <[EMAIL PROTECTED] >
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 <[EMAIL PROTECTED]> 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
>
