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
