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 a factory will be given to create a service (though this is mostly
hidden
by using spring).

I don't recall exacty what the exact problems are, but having a quick look
through
the code, i suppose the main problem comes from the OpenShellHandler which
is really dependant on plexus.  I will try to have a deeper look soon but
i'd be happy
to rewrite a few classes in a different way if needed for spring/osgi.

On Nov 13, 2007 3:35 AM, Jason Dillon <[EMAIL PROTECTED]> wrote:

> 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 of the annotations and descriptor generation
> bits to detach any plexus deps from the core command API, and well...
> Im starting to regret it.
>
> Going forward we will have <dependencies> for GShell plugin
> descriptors which I had planned to continue and follow Maven 2.1 as an
> example of how to make that work with Plexus.  The additional work and
> code required to abstract that functionality into something Plexus-
> agnostic is IMO not going to be worth it.  Perhaps later though once
> the main features of GShell are implemented and tested using Plexus we
> can work on abstracting the framework to allow for other IoC
> containers to be used instead, but ATM I'm thinking its best to get
> GShell working 100% with Plexus.
>
> --jason
>
>
> On Oct 11, 2007, at 9:41 AM, 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