Okay, I don't really know what OSGI is doing with classloaders, but as
before I'm willing to make changes to support your needs as long as
they fit inline witht he ongoing work using Plexus.
But for example, how do you plan to handle the section
of the gshell commands.xml descriptor with O
The problem with plexus is that objects are wired in a certain way, which
is not the way I want, mainly because I don't want plexus to mess with
my OSGi classloaders. For remoting support, I want to be able to configure
it through OSGi which means in my case that I define a set of properties
that
What do you need done here to use the RSH bits sans-Plexus?
Going forward I'm really wondering if I want to abstract the IoC bits
which Plexus provides or not. Seems like if I do want that, then I
have to duplicate a lot of what it provides for me already. I have
already duplicated some o
I will see about adding a TransportProvider abstraction to deal with
this...
I'm flying to Hawaii this weeken for a funeral :-( But I might have
time to look into this stuff then... else when I get back.
--jason
On Oct 12, 2007, at 3:48 PM, Guillaume Nodet wrote:
The core container has
The core container has only a few dependencies: one on
org.codehaus.plexus.personality.plexus.lifecycle.phase package and
several on org.codehaus.plexus.util package, but I don't have to
include the whole plexus to make gshell run, so I'm quite happy with
that.
However, whisper heavily rely on ple
I'm not actively trying to decouple Plexus from gshell-whisper... or
really any of GShel, though if I can add some abstraction to make it
easier for you to use GShell w/o Plexus I'm happy to do that as long
as it is not intrusive.
--jason
On Oct 11, 2007, at 12:41 PM, Guillaume Nodet wrot
So I've been able to have a local shell wired with Spring without
including any plexus jars in the classpath :-)
I'm trying to do the same with the remote shell, but it seems that
gshel-whisper is much more tied to plexus. Do you have any ongoing
modifications to decouple it a bit from plexus or c
FYI, I've found a workaround as Spring can solve such situations if
using property injection rather than constructor injection... So
creating wrapper solves the problem.
On 10/11/07, Guillaume Nodet <[EMAIL PROTECTED]> wrote:
> Ok, so it seems that wiring gshell using spring is not too difficult.
Ok, so it seems that wiring gshell using spring is not too difficult.
However I have seen a weird dependency between two POJOs which cause a
problem when wiring them. It happens between DefaultCommandExecutor
which has a dependency on OsgiCommandLineBuilder which also has a
dependency on the comm
Yep, that's what i did. I just mistyped in my email ...
I may also have to add constructors to a few classes (as done in other
classes) where they are missing...
On 10/11/07, Jason Dillon <[EMAIL PROTECTED]> wrote:
> Yup, sounds fine. As I mentioned to ya a while ago on IRC I took a
> few short
Yup, sounds fine. As I mentioned to ya a while ago on IRC I took a
few short cuts when I whipped this stuff up... after what now seems
like a long time ago.
Anyways, go for it. Only comment I've got is you should call the
intf CommandLineBuilder and the default impl
DefaultCommandLineBu
I'm trying to configure GShell through spring because spring can
integrate nicely in OSGi (which is my main purpose) and I just crossed
one problem: the CommandLineBuilder is a dependency of
DefaultCommandExecutor (in terms of POJOs). The problem is that
CommandLineBuilder is a class, not an inte
12 matches
Mail list logo
