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/

Reply via email to