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 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 plexus for the configuration of
transport, so I'll try to abstract that a bit (i'd be happy to
delegate that to you if you prefer). Mainly the BaseTransportFactory
class should rely on factories somehow instead of asking the container
to retrieve a new transport at each connection.
On 10/12/07, Jason Dillon <[EMAIL PROTECTED]> wrote:
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 wrote:
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 can I look at
that ?
On 10/11/07, Guillaume Nodet <[EMAIL PROTECTED]> wrote:
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.
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 command executor. Is there any way to refactor
things a bit to avoid this circular dependency ?
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 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
DefaultCommandLineBuilder (prefix insteand of suffix to follow
how
the other components play... ).
--jason
On Oct 11, 2007, at 6:46 AM, Guillaume Nodet wrote:
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 interface, with a strong
dependency on plexus. So I'd like to introduce an interface
CommandLineBuilder and rename the class as the default
implementation
CommandLineBuilderDefault. Any objections ?
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
