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/
