On Tue, Nov 18, 2008 at 1:51 PM, David Jencks <[EMAIL PROTECTED]> wrote: > > The previous way we did this was to keep the minimal possible stuff in lib > and fire up a geronimo kernel with a repository gbean in it to abstract the > actual structure of the repo for command line clients. My (quite possibly > wrong) understanding is that gshell is doing something similar using some > ivy classes. > > Can you write these plugins to depend on the client-system plugin and run > them as app clients?
Well, I can fix my particular problem by either dumping geronimo-system.jar into the "lib" dir or by moving some classes (e.g. RepositoryConfigurationStore.java) from geronimo-system to geronimo-kernel. Let me if either of these sounds good to you. I don't really want to start up a whole app container just to execute some command line tool. I did look into booting a basic kernel with a repo gbean (sort of what deployer or client does) but that will require a separate plugin. And I already have two plugins just to deploy and install the jaxws tooling. I guess I should re-consider this option. > I have to say I'm not very happy about the current state of geronimo > startup. IIUC gshell is using spring, ivy, and ant to set up the jvm for > geronimo which is then using the geronimo kernel to set up a whole other set > of classloaders using imitation maven classes. I surely don't have a > solution but this seems just too complex with too much duplicated > functionality to me. Btw, the version of GShell used in Geronimo trunk just loads the jar files from the lib or the repository directory as specified in the etc/gsh-classworlds.conf file. Jarek
