You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Guillaume Nodet <gn...@gmail.com> on 2007/10/11 15:46:28 UTC
[GShell] Plexus dependency in CommandLineBuilder
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/
Re: [GShell] Plexus dependency in CommandLineBuilder
Posted by Jason Dillon <ja...@planet57.com>.
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 <dependencies> section
of the gshell commands.xml descriptor with OSGI?
--jason
On Nov 13, 2007, at 12:54 AM, Guillaume Nodet wrote:
> 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 <ja...@planet57.com> 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 <gn...@gmail.com> 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 <gn...@gmail.com> 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 <ja...@planet57.com> 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/
Re: [GShell] Plexus dependency in CommandLineBuilder
Posted by Guillaume Nodet <gn...@gmail.com>.
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 <ja...@planet57.com> 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 <gn...@gmail.com> 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 <gn...@gmail.com> 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 <ja...@planet57.com> 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/
Re: [GShell] Plexus dependency in CommandLineBuilder
Posted by Jason Dillon <ja...@planet57.com>.
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 <gn...@gmail.com> 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 <gn...@gmail.com> 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 <ja...@planet57.com> 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/
Re: [GShell] Plexus dependency in CommandLineBuilder
Posted by Jason Dillon <ja...@planet57.com>.
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 <ja...@planet57.com> 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 <gn...@gmail.com> 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 <gn...@gmail.com> 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 <ja...@planet57.com> 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/
Re: [GShell] Plexus dependency in CommandLineBuilder
Posted by Guillaume Nodet <gn...@gmail.com>.
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 <ja...@planet57.com> 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 <gn...@gmail.com> 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 <gn...@gmail.com> 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 <ja...@planet57.com> 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/
Re: [GShell] Plexus dependency in CommandLineBuilder
Posted by Jason Dillon <ja...@planet57.com>.
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 <gn...@gmail.com> 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 <gn...@gmail.com> 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 <ja...@planet57.com> 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/
Re: [GShell] Plexus dependency in CommandLineBuilder
Posted by Guillaume Nodet <gn...@gmail.com>.
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 <gn...@gmail.com> 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 <gn...@gmail.com> 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 <ja...@planet57.com> 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/
Re: [GShell] Plexus dependency in CommandLineBuilder
Posted by Guillaume Nodet <gn...@gmail.com>.
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 <gn...@gmail.com> 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 <ja...@planet57.com> 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/
Re: [GShell] Plexus dependency in CommandLineBuilder
Posted by Guillaume Nodet <gn...@gmail.com>.
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 <ja...@planet57.com> 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/
Re: [GShell] Plexus dependency in CommandLineBuilder
Posted by Guillaume Nodet <gn...@gmail.com>.
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 <ja...@planet57.com> 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/
Re: [GShell] Plexus dependency in CommandLineBuilder
Posted by Jason Dillon <ja...@planet57.com>.
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/