You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Rahul Thakur <ra...@gmail.com> on 2008/03/14 05:08:19 UTC
Re: XBean and DI?
Hi Jason,
Is this hosted somewhere where we can take a look or start poking around?
Cheers,
Rahul
Jason van Zyl wrote:
>
> On 28-Feb-08, at 3:00 PM, Barrie Treloar wrote:
>
>> Jason, do you want to talk some more about XBean, DI, & Maven/Plexus etc?
>>
>
> XBean Reflect (XBR) is really something more akin to Guice. XBR is more
> complete then what I have in Plexus and I honestly only ever cared about
> private field injection and Plexus only does constructor and setter
> injection now. XBR does private field, constructor, bean factory, and
> setter injections. Dain and I chatted and decided to come up with an
> interface for DI that XBR would provide and that Plexus could consume.
> Dain has done the XBR side and is now going to remove Plexus' DI in
> favor of XBR. XBR is currently used in OpenEJB and David Jencks might be
> interested in it for Geronimo. So that would be the first step of
> collapsing out the DI code in Plexus and using XBR as a library.
>
> I have also been talking with the Pico folks and if we could then
> abstract some container features I would be happy to chop out another
> huge chunk of Plexus and use Pico. So I'm hoping that we can arrive at
> the interface for DI which Pico and Plexus can use, and then take the
> bottom out of Plexus and use Pico in there. Ultimately the features I
> have in Plexus that I like are specifically for plugin systems like
> Maven. I have mechanisms for component configuration, configuration
> sources which can configure multiple components (like an application
> specific configuration being mapped on to components, this is what is
> done in Nexus), dynamic metadata translation (maven plugins are plexus
> components which are flipped on the fly), dynamic component discovery
> (maven plugins don't exist anywhere in the system until they are
> downloaded and wired up in the container), and runtime nature of a
> component system. Really this is what I am interested in and if Dain,
> Paul, Mauro, Peter want to do the DI and base container stuff that's
> great. We have all made containers and while it's very interesting we
> all go to bed at 10pm now, have lives (well some of us) and if we want
> any traction we know we have to work together. Dain, Paul and myself
> have been trying to hash this out for 4 years while things like Spring
> just took over, and things like Juice popped up. We're trying to take
> our personalities out of the equation (and that is very, very, very hard
> as we're all territorial which is good and bad) and make a better system.
>
> The other interesting thing is that Dain sees JAXB as being an almost
> complete DI system itself. So if we create this interface and we can get
> Kohsuke to mess around with JAXB then maybe we can throw all our stuff
> away and let JAXB do the DI. That's where we're headed and it finally
> looks like we're making some headway. Dain will probably be done the
> first pass next week sometime and then we'll spend a week finding all
> the problems by running the Maven ITs. None of us are interested in
> using Spring but we're interested in running Spring applications which
> there are chunks of code lying around. And none of us are really
> interested in using OSGi but definitely want to interoperate (I actually
> had a good chat with Jeff McAffer and we actually talked about what
> would need to be done to run Maven on OSGi). We all like containers and
> want to continue working on them and we realize we can work on more
> interesting problems if we work together. This may seem perfectly
> obviously but it's been nearly impossible to get this point. Dain, Paul,
> and myself are very similar and in the past many of the conversation
> would go something like "Hmm, that's nice. My container can do this, my
> container can do that ... yada yada yada." Meanwhile many other systems
> have cropped up and served people better. I'm not a big fan of Spring's
> internals or architecture but absolutely no one can argue with their
> dedication to users, good documentation, helpful community and we
> realize we've done a disservice to people using our stuff because we
> can't cooperate. The merger of XBR into Plexus will be the first step
> away from this pattern and it's almost done.
>
>> I've had a brief look at http://geronimo.apache.org/xbean/index.html
>> but some of the pages are thin and the diagrams are coming up with
>> exceptions.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder, Apache Maven
> jason at sonatype dot com
> ----------------------------------------------------------
>
> We know what we are, but know not what we may be.
>
> -- Shakespeare
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: XBean and DI?
Posted by Jason van Zyl <jv...@sonatype.com>.
Dain is here.
On 27-Feb-09, at 12:27 PM, Mark Hobson wrote:
> 2008/9/25 Jason van Zyl <ja...@maven.org>:
>> I suggest you both talk to Dain and see about integrating it into
>> XBean.
>> XBean is used for all of Geronimo's EE injection and Dain/David are
>> pretty
>> thorough. I'm not planning on using anything else on trunk.
>
> Just to follow up on this old thread. I've recently open-sourced the
> small generic types library I was talking about after discussions with
> the Hibernate Bean Validation team who needed something similar. It's
> currently hosted here:
>
> http://code.google.com/p/jtype/
>
> I welcome contributions from others who have worked in this domain
> before in order to centralise our efforts. Jason, is Dain on this
> list if he would be interested, or shall I ping him directly?
>
> Cheers,
>
> Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: XBean and DI?
Posted by Mark Hobson <ma...@gmail.com>.
2008/9/25 Jason van Zyl <ja...@maven.org>:
> I suggest you both talk to Dain and see about integrating it into XBean.
> XBean is used for all of Geronimo's EE injection and Dain/David are pretty
> thorough. I'm not planning on using anything else on trunk.
Just to follow up on this old thread. I've recently open-sourced the
small generic types library I was talking about after discussions with
the Hibernate Bean Validation team who needed something similar. It's
currently hosted here:
http://code.google.com/p/jtype/
I welcome contributions from others who have worked in this domain
before in order to centralise our efforts. Jason, is Dain on this
list if he would be interested, or shall I ping him directly?
Cheers,
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: XBean and DI?
Posted by Jason van Zyl <ja...@maven.org>.
If you want to join the effort on something that will be used in Maven
then talk to the XBean people. I've ditched the guts of Plexus'
internal DI for XBean and I'll work with Dain/David to make any
improvements there. I'm just happy constructor and factory bean
injection is now possible. I'm not really worried about generics/
reflection problems to be honest. Lots of other things to worry about
but I'm sure Dain will chat with you about it.
On 25-Sep-08, at 5:20 PM, Simone Gianni wrote:
> Hi all,
> sorry for jumping in and maybe being off topic, but the problem of
> generics erasure and reflection also bugged me in my Apache Lab, and I
> also came up with a small library to avoid reinventing the wheel any
> time, and was recently proposing it to people in Apache Commons. They
> said that there could be space for such a thing in commons-lang, and I
> feel that if there is a place in ASF for such utility stuff is in
> commons. You can find the thread here :
> http://www.nabble.com/-all--Generics-and-Return-Type--tt16595948.html#a19605981
>
> I don't know how much this is related, cause I don't know Xbeans to
> understand if the connection is proper, but seems like many of us are
> working on very similar stuff, and we could join the effort.
>
> Simone
>
> Jason van Zyl wrote:
>> I suggest you both talk to Dain and see about integrating it into
>> XBean. XBean is used for all of Geronimo's EE injection and Dain/
>> David
>> are pretty thorough. I'm not planning on using anything else on
>> trunk.
>>
>> On 25-Sep-08, at 10:15 AM, Mark Hobson wrote:
>>
>>> 2008/9/24 Joerg Hohwiller <jo...@j-hohwiller.de>:
>>>>> Also xbean-reflect "thinks" in java.lang.reflect.Type terms so
>>>>> it's
>>>>> easy
>>>>> to add converters that are generics-aware. For example I recently
>>>>> added
>>>>> converters for Map<K,V> and Set<T> and List<T> and it only took an
>>>>> hour.
>>>>
>>>> I spent the last year with creating support for this.
>>>> You have to rebuild all the stuff that is in javac but missing in
>>>> the JDK.
>>>> The erasure was maybe the only way to introduce generics but it
>>>> is a
>>>> real pain. I almost got braindead with this.
>>>>
>>>> Is <? super CharSequence>.isAssignableFrom(<? super String>)
>>>> or vice versa?
>>>
>>> FWIW, I've written a small library here internally for working with
>>> Types that:
>>>
>>> - provides a factory to create the various incarnations
>>> - implements isAssignable and other useful Class methods for Types
>>> - formats and parses Types to and from Strings
>>> - provides type literals (like Guice's TypeLiteral)
>>>
>>> I agree this kind of code should be available in the JDK to prevent
>>> people from reinventing the wheel. If there's any interest I could
>>> look into open-sourcing it?
>>>
>>> Cheers,
>>>
>>> Mark
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>
>> Thanks,
>>
>> Jason
>>
>> ----------------------------------------------------------
>> Jason van Zyl
>> Founder, Apache Maven
>> jason at sonatype dot com
>> ----------------------------------------------------------
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
>
> --
> Simone Gianni CEO Semeru s.r.l. Apache Committer
> MALE human being programming a computer http://www.simonegianni.it/
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
First, the taking in of scattered particulars under one Idea,
so that everyone understands what is being talked about ... Second,
the separation of the Idea into parts, by dividing it at the joints,
as nature directs, not breaking any limb in half as a bad carver might.
-- Plato, Phaedrus (Notes on the Synthesis of Form by C. Alexander)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: XBean and DI?
Posted by Simone Gianni <si...@apache.org>.
Hi all,
sorry for jumping in and maybe being off topic, but the problem of
generics erasure and reflection also bugged me in my Apache Lab, and I
also came up with a small library to avoid reinventing the wheel any
time, and was recently proposing it to people in Apache Commons. They
said that there could be space for such a thing in commons-lang, and I
feel that if there is a place in ASF for such utility stuff is in
commons. You can find the thread here :
http://www.nabble.com/-all--Generics-and-Return-Type--tt16595948.html#a19605981
I don't know how much this is related, cause I don't know Xbeans to
understand if the connection is proper, but seems like many of us are
working on very similar stuff, and we could join the effort.
Simone
Jason van Zyl wrote:
> I suggest you both talk to Dain and see about integrating it into
> XBean. XBean is used for all of Geronimo's EE injection and Dain/David
> are pretty thorough. I'm not planning on using anything else on trunk.
>
> On 25-Sep-08, at 10:15 AM, Mark Hobson wrote:
>
>> 2008/9/24 Joerg Hohwiller <jo...@j-hohwiller.de>:
>>>> Also xbean-reflect "thinks" in java.lang.reflect.Type terms so it's
>>>> easy
>>>> to add converters that are generics-aware. For example I recently
>>>> added
>>>> converters for Map<K,V> and Set<T> and List<T> and it only took an
>>>> hour.
>>>
>>> I spent the last year with creating support for this.
>>> You have to rebuild all the stuff that is in javac but missing in
>>> the JDK.
>>> The erasure was maybe the only way to introduce generics but it is a
>>> real pain. I almost got braindead with this.
>>>
>>> Is <? super CharSequence>.isAssignableFrom(<? super String>)
>>> or vice versa?
>>
>> FWIW, I've written a small library here internally for working with
>> Types that:
>>
>> - provides a factory to create the various incarnations
>> - implements isAssignable and other useful Class methods for Types
>> - formats and parses Types to and from Strings
>> - provides type literals (like Guice's TypeLiteral)
>>
>> I agree this kind of code should be available in the JDK to prevent
>> people from reinventing the wheel. If there's any interest I could
>> look into open-sourcing it?
>>
>> Cheers,
>>
>> Mark
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder, Apache Maven
> jason at sonatype dot com
> ----------------------------------------------------------
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
--
Simone Gianni CEO Semeru s.r.l. Apache Committer
MALE human being programming a computer http://www.simonegianni.it/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: XBean and DI?
Posted by Jason van Zyl <ja...@maven.org>.
I suggest you both talk to Dain and see about integrating it into
XBean. XBean is used for all of Geronimo's EE injection and Dain/David
are pretty thorough. I'm not planning on using anything else on trunk.
On 25-Sep-08, at 10:15 AM, Mark Hobson wrote:
> 2008/9/24 Joerg Hohwiller <jo...@j-hohwiller.de>:
>>> Also xbean-reflect "thinks" in java.lang.reflect.Type terms so
>>> it's easy
>>> to add converters that are generics-aware. For example I recently
>>> added
>>> converters for Map<K,V> and Set<T> and List<T> and it only took an
>>> hour.
>>
>> I spent the last year with creating support for this.
>> You have to rebuild all the stuff that is in javac but missing in
>> the JDK.
>> The erasure was maybe the only way to introduce generics but it is a
>> real pain. I almost got braindead with this.
>>
>> Is <? super CharSequence>.isAssignableFrom(<? super String>)
>> or vice versa?
>
> FWIW, I've written a small library here internally for working with
> Types that:
>
> - provides a factory to create the various incarnations
> - implements isAssignable and other useful Class methods for Types
> - formats and parses Types to and from Strings
> - provides type literals (like Guice's TypeLiteral)
>
> I agree this kind of code should be available in the JDK to prevent
> people from reinventing the wheel. If there's any interest I could
> look into open-sourcing it?
>
> Cheers,
>
> Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: XBean and DI?
Posted by Mark Hobson <ma...@gmail.com>.
2008/9/24 Joerg Hohwiller <jo...@j-hohwiller.de>:
>> Also xbean-reflect "thinks" in java.lang.reflect.Type terms so it's easy
>> to add converters that are generics-aware. For example I recently added
>> converters for Map<K,V> and Set<T> and List<T> and it only took an hour.
>
> I spent the last year with creating support for this.
> You have to rebuild all the stuff that is in javac but missing in the JDK.
> The erasure was maybe the only way to introduce generics but it is a
> real pain. I almost got braindead with this.
>
> Is <? super CharSequence>.isAssignableFrom(<? super String>)
> or vice versa?
FWIW, I've written a small library here internally for working with Types that:
- provides a factory to create the various incarnations
- implements isAssignable and other useful Class methods for Types
- formats and parses Types to and from Strings
- provides type literals (like Guice's TypeLiteral)
I agree this kind of code should be available in the JDK to prevent
people from reinventing the wheel. If there's any interest I could
look into open-sourcing it?
Cheers,
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: XBean and DI?
Posted by Joerg Hohwiller <jo...@j-hohwiller.de>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi there,
>> The additions Dain has made to XBean adds things I was just never
>> interested in like constructor injection and bean factories.
>
> Also xbean-reflect "thinks" in java.lang.reflect.Type terms so it's easy
> to add converters that are generics-aware. For example I recently added
> converters for Map<K,V> and Set<T> and List<T> and it only took an hour.
I spent the last year with creating support for this.
You have to rebuild all the stuff that is in javac but missing in the JDK.
The erasure was maybe the only way to introduce generics but it is a
real pain. I almost got braindead with this.
Is <? super CharSequence>.isAssignableFrom(<? super String>)
or vice versa?
Could not find the time to have a look at XBean but I doubt its
doing the stuff right with java.lang.reflect.Type.
Please let me know if I am wrong.
Write some class Foo extends List<String>
and then Bar<E> extends Foo
further Some extends Bar<Integer>.
Now let me know if XBean tells you that
Some.get(int) has the return-type String.
My implementation does...
Maybe you want to have a look.
However still in progress of improving,
so you might NOT want to use it now...
<https://m-m-m.svn.sourceforge.net/svnroot/m-m-m/trunk/mmm-util/mmm-util-core/src/main/java/net/sf/mmm/util/reflect/api/GenericType.java>
Site has NOT be updated for a while but also
<http://m-m-m.sourceforge.net/maven/mmm-util/mmm-util-core/index.html>
<http://m-m-m.sourceforge.net/maven/mmm-util/mmm-util-pojo/index.html>
>
> Just in general the code is pretty small and tight as well and generally
> very easy to add features.
>
> -David
Regards
Jörg
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFI2p5PmPuec2Dcv/8RApPgAJ9n5f9eeNVBVukFTx6vFThacyI/0gCcDPyw
tNxIS2JZbqwtmcV8JkZCV2A=
=3ikU
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: XBean and DI?
Posted by David Blevins <da...@visi.com>.
On Mar 14, 2008, at 8:24 AM, Jason van Zyl wrote:
> The additions Dain has made to XBean adds things I was just never
> interested in like constructor injection and bean factories.
Also xbean-reflect "thinks" in java.lang.reflect.Type terms so it's
easy to add converters that are generics-aware. For example I
recently added converters for Map<K,V> and Set<T> and List<T> and it
only took an hour.
Just in general the code is pretty small and tight as well and
generally very easy to add features.
-David
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: XBean and DI?
Posted by Jason van Zyl <ja...@maven.org>.
On 14-Mar-08, at 2:55 AM, Milos Kleint wrote:
> is there any document describing the gains of such rewrite? I assume
> more features and less bugs are an obvious plus of code reuse, but is
> there more?
>
That there would be more developers working on the core. Dain, and
David use XBean extensively in OpenEJB and what we're trying to create
is a DI library and so we will also be collaborating with Paul/Mauro/
Pete to make this work across all our projects. The additions Dain has
made to XBean adds things I was just never interested in like
constructor injection and bean factories. It's really the reduction of
the code in Plexus to use a library with more developers and more
functionality.
> I'm interested in this are especially because I do all sorts of
> dynamic component replacement within an IDE embedded maven instance..
> So I'm wondering if it makes my life easier or maybe not..
>
What Dain is planning is far more flexible for integration. OpenEJB is
all about integration and so it deals better with live instances for
certain. There are many other container aspects to our collaboration
but this is just the first step and it won't be noticed at first
because Plexus itself will limit the visibility of the extended
capabilities in XBR. I just don't want to maintain the DI aspect of
this anymore, it's not the interesting part for me in Maven, it's the
other features in Plexus that make Maven work.
> Milos
>
>
> On Fri, Mar 14, 2008 at 7:32 AM, Jason van Zyl <ja...@maven.org>
> wrote:
>> On Dain's side it's all in the XBean repository, which a sub-project
>> in geronimo. The changes to Plexus need to be made. Dain is still
>> working on that. But the DI api which is the interesting thing is all
>> in XBean.
>>
>>
>>
>> On 13-Mar-08, at 9:08 PM, Rahul Thakur wrote:
>>
>>> Hi Jason,
>>>
>>> Is this hosted somewhere where we can take a look or start poking
>>> around?
>>>
>>> Cheers,
>>> Rahul
>>>
>>>
>>>
>>>
>>> Jason van Zyl wrote:
>>>>
>>>> On 28-Feb-08, at 3:00 PM, Barrie Treloar wrote:
>>>>
>>>>> Jason, do you want to talk some more about XBean, DI, & Maven/
>>>>> Plexus etc?
>>>>>
>>>>
>>>> XBean Reflect (XBR) is really something more akin to Guice. XBR is
>>>> more
>>>> complete then what I have in Plexus and I honestly only ever cared
>>>> about
>>>> private field injection and Plexus only does constructor and setter
>>>> injection now. XBR does private field, constructor, bean factory,
>>>> and
>>>> setter injections. Dain and I chatted and decided to come up with
>>>> an
>>>> interface for DI that XBR would provide and that Plexus could
>>>> consume.
>>>> Dain has done the XBR side and is now going to remove Plexus' DI in
>>>> favor of XBR. XBR is currently used in OpenEJB and David Jencks
>>>> might be
>>>> interested in it for Geronimo. So that would be the first step of
>>>> collapsing out the DI code in Plexus and using XBR as a library.
>>>>
>>>> I have also been talking with the Pico folks and if we could then
>>>> abstract some container features I would be happy to chop out
>>>> another
>>>> huge chunk of Plexus and use Pico. So I'm hoping that we can arrive
>>>> at
>>>> the interface for DI which Pico and Plexus can use, and then take
>>>> the
>>>> bottom out of Plexus and use Pico in there. Ultimately the
>>>> features I
>>>> have in Plexus that I like are specifically for plugin systems like
>>>> Maven. I have mechanisms for component configuration, configuration
>>>> sources which can configure multiple components (like an
>>>> application
>>>> specific configuration being mapped on to components, this is
>>>> what is
>>>> done in Nexus), dynamic metadata translation (maven plugins are
>>>> plexus
>>>> components which are flipped on the fly), dynamic component
>>>> discovery
>>>> (maven plugins don't exist anywhere in the system until they are
>>>> downloaded and wired up in the container), and runtime nature of a
>>>> component system. Really this is what I am interested in and if
>>>> Dain,
>>>> Paul, Mauro, Peter want to do the DI and base container stuff
>>>> that's
>>>> great. We have all made containers and while it's very
>>>> interesting we
>>>> all go to bed at 10pm now, have lives (well some of us) and if we
>>>> want
>>>> any traction we know we have to work together. Dain, Paul and
>>>> myself
>>>> have been trying to hash this out for 4 years while things like
>>>> Spring
>>>> just took over, and things like Juice popped up. We're trying to
>>>> take
>>>> our personalities out of the equation (and that is very, very, very
>>>> hard
>>>> as we're all territorial which is good and bad) and make a better
>>>> system.
>>>>
>>>> The other interesting thing is that Dain sees JAXB as being an
>>>> almost
>>>> complete DI system itself. So if we create this interface and we
>>>> can get
>>>> Kohsuke to mess around with JAXB then maybe we can throw all our
>>>> stuff
>>>> away and let JAXB do the DI. That's where we're headed and it
>>>> finally
>>>> looks like we're making some headway. Dain will probably be done
>>>> the
>>>> first pass next week sometime and then we'll spend a week finding
>>>> all
>>>> the problems by running the Maven ITs. None of us are interested in
>>>> using Spring but we're interested in running Spring applications
>>>> which
>>>> there are chunks of code lying around. And none of us are really
>>>> interested in using OSGi but definitely want to interoperate (I
>>>> actually
>>>> had a good chat with Jeff McAffer and we actually talked about what
>>>> would need to be done to run Maven on OSGi). We all like containers
>>>> and
>>>> want to continue working on them and we realize we can work on more
>>>> interesting problems if we work together. This may seem perfectly
>>>> obviously but it's been nearly impossible to get this point. Dain,
>>>> Paul,
>>>> and myself are very similar and in the past many of the
>>>> conversation
>>>> would go something like "Hmm, that's nice. My container can do
>>>> this, my
>>>> container can do that ... yada yada yada." Meanwhile many other
>>>> systems
>>>> have cropped up and served people better. I'm not a big fan of
>>>> Spring's
>>>> internals or architecture but absolutely no one can argue with
>>>> their
>>>> dedication to users, good documentation, helpful community and we
>>>> realize we've done a disservice to people using our stuff because
>>>> we
>>>> can't cooperate. The merger of XBR into Plexus will be the first
>>>> step
>>>> away from this pattern and it's almost done.
>>>>
>>>>> I've had a brief look at http://geronimo.apache.org/xbean/index.html
>>>>> but some of the pages are thin and the diagrams are coming up with
>>>>> exceptions.
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>
>>>>
>>>> Thanks,
>>>>
>>>> Jason
>>>>
>>>> ----------------------------------------------------------
>>>> Jason van Zyl
>>>> Founder, Apache Maven
>>>> jason at sonatype dot com
>>>> ----------------------------------------------------------
>>>>
>>>> We know what we are, but know not what we may be.
>>>>
>>>> -- Shakespeare
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>
>> Thanks,
>>
>> Jason
>>
>> ----------------------------------------------------------
>> Jason van Zyl
>> Founder, Apache Maven
>> jason at sonatype dot com
>> ----------------------------------------------------------
>>
>> believe nothing, no matter where you read it,
>> or who has said it,
>> not even if i have said it,
>> unless it agrees with your own reason
>> and your own common sense.
>>
>> -- Buddha
>>
>>
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
A language that doesn’t affect the way you think about programming is
not worth knowing.
-— Alan Perlis
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: XBean and DI?
Posted by Milos Kleint <mk...@gmail.com>.
is there any document describing the gains of such rewrite? I assume
more features and less bugs are an obvious plus of code reuse, but is
there more?
I'm interested in this are especially because I do all sorts of
dynamic component replacement within an IDE embedded maven instance..
So I'm wondering if it makes my life easier or maybe not..
Milos
On Fri, Mar 14, 2008 at 7:32 AM, Jason van Zyl <ja...@maven.org> wrote:
> On Dain's side it's all in the XBean repository, which a sub-project
> in geronimo. The changes to Plexus need to be made. Dain is still
> working on that. But the DI api which is the interesting thing is all
> in XBean.
>
>
>
> On 13-Mar-08, at 9:08 PM, Rahul Thakur wrote:
>
> > Hi Jason,
> >
> > Is this hosted somewhere where we can take a look or start poking
> > around?
> >
> > Cheers,
> > Rahul
> >
> >
> >
> >
> > Jason van Zyl wrote:
> >>
> >> On 28-Feb-08, at 3:00 PM, Barrie Treloar wrote:
> >>
> >>> Jason, do you want to talk some more about XBean, DI, & Maven/
> >>> Plexus etc?
> >>>
> >>
> >> XBean Reflect (XBR) is really something more akin to Guice. XBR is
> >> more
> >> complete then what I have in Plexus and I honestly only ever cared
> >> about
> >> private field injection and Plexus only does constructor and setter
> >> injection now. XBR does private field, constructor, bean factory, and
> >> setter injections. Dain and I chatted and decided to come up with an
> >> interface for DI that XBR would provide and that Plexus could
> >> consume.
> >> Dain has done the XBR side and is now going to remove Plexus' DI in
> >> favor of XBR. XBR is currently used in OpenEJB and David Jencks
> >> might be
> >> interested in it for Geronimo. So that would be the first step of
> >> collapsing out the DI code in Plexus and using XBR as a library.
> >>
> >> I have also been talking with the Pico folks and if we could then
> >> abstract some container features I would be happy to chop out another
> >> huge chunk of Plexus and use Pico. So I'm hoping that we can arrive
> >> at
> >> the interface for DI which Pico and Plexus can use, and then take the
> >> bottom out of Plexus and use Pico in there. Ultimately the features I
> >> have in Plexus that I like are specifically for plugin systems like
> >> Maven. I have mechanisms for component configuration, configuration
> >> sources which can configure multiple components (like an application
> >> specific configuration being mapped on to components, this is what is
> >> done in Nexus), dynamic metadata translation (maven plugins are
> >> plexus
> >> components which are flipped on the fly), dynamic component discovery
> >> (maven plugins don't exist anywhere in the system until they are
> >> downloaded and wired up in the container), and runtime nature of a
> >> component system. Really this is what I am interested in and if Dain,
> >> Paul, Mauro, Peter want to do the DI and base container stuff that's
> >> great. We have all made containers and while it's very interesting we
> >> all go to bed at 10pm now, have lives (well some of us) and if we
> >> want
> >> any traction we know we have to work together. Dain, Paul and myself
> >> have been trying to hash this out for 4 years while things like
> >> Spring
> >> just took over, and things like Juice popped up. We're trying to take
> >> our personalities out of the equation (and that is very, very, very
> >> hard
> >> as we're all territorial which is good and bad) and make a better
> >> system.
> >>
> >> The other interesting thing is that Dain sees JAXB as being an almost
> >> complete DI system itself. So if we create this interface and we
> >> can get
> >> Kohsuke to mess around with JAXB then maybe we can throw all our
> >> stuff
> >> away and let JAXB do the DI. That's where we're headed and it finally
> >> looks like we're making some headway. Dain will probably be done the
> >> first pass next week sometime and then we'll spend a week finding all
> >> the problems by running the Maven ITs. None of us are interested in
> >> using Spring but we're interested in running Spring applications
> >> which
> >> there are chunks of code lying around. And none of us are really
> >> interested in using OSGi but definitely want to interoperate (I
> >> actually
> >> had a good chat with Jeff McAffer and we actually talked about what
> >> would need to be done to run Maven on OSGi). We all like containers
> >> and
> >> want to continue working on them and we realize we can work on more
> >> interesting problems if we work together. This may seem perfectly
> >> obviously but it's been nearly impossible to get this point. Dain,
> >> Paul,
> >> and myself are very similar and in the past many of the conversation
> >> would go something like "Hmm, that's nice. My container can do
> >> this, my
> >> container can do that ... yada yada yada." Meanwhile many other
> >> systems
> >> have cropped up and served people better. I'm not a big fan of
> >> Spring's
> >> internals or architecture but absolutely no one can argue with their
> >> dedication to users, good documentation, helpful community and we
> >> realize we've done a disservice to people using our stuff because we
> >> can't cooperate. The merger of XBR into Plexus will be the first step
> >> away from this pattern and it's almost done.
> >>
> >>> I've had a brief look at http://geronimo.apache.org/xbean/index.html
> >>> but some of the pages are thin and the diagrams are coming up with
> >>> exceptions.
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>
> >>
> >> Thanks,
> >>
> >> Jason
> >>
> >> ----------------------------------------------------------
> >> Jason van Zyl
> >> Founder, Apache Maven
> >> jason at sonatype dot com
> >> ----------------------------------------------------------
> >>
> >> We know what we are, but know not what we may be.
> >>
> >> -- Shakespeare
> >>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: dev-help@maven.apache.org
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder, Apache Maven
> jason at sonatype dot com
> ----------------------------------------------------------
>
> believe nothing, no matter where you read it,
> or who has said it,
> not even if i have said it,
> unless it agrees with your own reason
> and your own common sense.
>
> -- Buddha
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: XBean and DI?
Posted by Jason van Zyl <ja...@maven.org>.
On Dain's side it's all in the XBean repository, which a sub-project
in geronimo. The changes to Plexus need to be made. Dain is still
working on that. But the DI api which is the interesting thing is all
in XBean.
On 13-Mar-08, at 9:08 PM, Rahul Thakur wrote:
> Hi Jason,
>
> Is this hosted somewhere where we can take a look or start poking
> around?
>
> Cheers,
> Rahul
>
>
>
>
> Jason van Zyl wrote:
>>
>> On 28-Feb-08, at 3:00 PM, Barrie Treloar wrote:
>>
>>> Jason, do you want to talk some more about XBean, DI, & Maven/
>>> Plexus etc?
>>>
>>
>> XBean Reflect (XBR) is really something more akin to Guice. XBR is
>> more
>> complete then what I have in Plexus and I honestly only ever cared
>> about
>> private field injection and Plexus only does constructor and setter
>> injection now. XBR does private field, constructor, bean factory, and
>> setter injections. Dain and I chatted and decided to come up with an
>> interface for DI that XBR would provide and that Plexus could
>> consume.
>> Dain has done the XBR side and is now going to remove Plexus' DI in
>> favor of XBR. XBR is currently used in OpenEJB and David Jencks
>> might be
>> interested in it for Geronimo. So that would be the first step of
>> collapsing out the DI code in Plexus and using XBR as a library.
>>
>> I have also been talking with the Pico folks and if we could then
>> abstract some container features I would be happy to chop out another
>> huge chunk of Plexus and use Pico. So I'm hoping that we can arrive
>> at
>> the interface for DI which Pico and Plexus can use, and then take the
>> bottom out of Plexus and use Pico in there. Ultimately the features I
>> have in Plexus that I like are specifically for plugin systems like
>> Maven. I have mechanisms for component configuration, configuration
>> sources which can configure multiple components (like an application
>> specific configuration being mapped on to components, this is what is
>> done in Nexus), dynamic metadata translation (maven plugins are
>> plexus
>> components which are flipped on the fly), dynamic component discovery
>> (maven plugins don't exist anywhere in the system until they are
>> downloaded and wired up in the container), and runtime nature of a
>> component system. Really this is what I am interested in and if Dain,
>> Paul, Mauro, Peter want to do the DI and base container stuff that's
>> great. We have all made containers and while it's very interesting we
>> all go to bed at 10pm now, have lives (well some of us) and if we
>> want
>> any traction we know we have to work together. Dain, Paul and myself
>> have been trying to hash this out for 4 years while things like
>> Spring
>> just took over, and things like Juice popped up. We're trying to take
>> our personalities out of the equation (and that is very, very, very
>> hard
>> as we're all territorial which is good and bad) and make a better
>> system.
>>
>> The other interesting thing is that Dain sees JAXB as being an almost
>> complete DI system itself. So if we create this interface and we
>> can get
>> Kohsuke to mess around with JAXB then maybe we can throw all our
>> stuff
>> away and let JAXB do the DI. That's where we're headed and it finally
>> looks like we're making some headway. Dain will probably be done the
>> first pass next week sometime and then we'll spend a week finding all
>> the problems by running the Maven ITs. None of us are interested in
>> using Spring but we're interested in running Spring applications
>> which
>> there are chunks of code lying around. And none of us are really
>> interested in using OSGi but definitely want to interoperate (I
>> actually
>> had a good chat with Jeff McAffer and we actually talked about what
>> would need to be done to run Maven on OSGi). We all like containers
>> and
>> want to continue working on them and we realize we can work on more
>> interesting problems if we work together. This may seem perfectly
>> obviously but it's been nearly impossible to get this point. Dain,
>> Paul,
>> and myself are very similar and in the past many of the conversation
>> would go something like "Hmm, that's nice. My container can do
>> this, my
>> container can do that ... yada yada yada." Meanwhile many other
>> systems
>> have cropped up and served people better. I'm not a big fan of
>> Spring's
>> internals or architecture but absolutely no one can argue with their
>> dedication to users, good documentation, helpful community and we
>> realize we've done a disservice to people using our stuff because we
>> can't cooperate. The merger of XBR into Plexus will be the first step
>> away from this pattern and it's almost done.
>>
>>> I've had a brief look at http://geronimo.apache.org/xbean/index.html
>>> but some of the pages are thin and the diagrams are coming up with
>>> exceptions.
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>
>> Thanks,
>>
>> Jason
>>
>> ----------------------------------------------------------
>> Jason van Zyl
>> Founder, Apache Maven
>> jason at sonatype dot com
>> ----------------------------------------------------------
>>
>> We know what we are, but know not what we may be.
>>
>> -- Shakespeare
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
believe nothing, no matter where you read it,
or who has said it,
not even if i have said it,
unless it agrees with your own reason
and your own common sense.
-- Buddha
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org