I agree that we need to join forces. Actually, i have started experimenting with xbean-refect after having seen your code :-)
If we are going to use generics in the implementation, it may be easier to use the reflect package implementation classes that i wrote. Anyway, I think the main difference is that the one Rick wrote allow deep copy of values with a copy constructor. Rick, have you seen such a need anywhere in the spec ? While implementing the parser, I haven't seen the need for it so I wonder if we need to keep that or not. The parser has dependencies on those classes, so we need to merge / refactor here. I'm currently working on integrating your code into mine, but we could do the opposite if you prefer. On Mon, Apr 13, 2009 at 22:17, Jarek Gawor <[email protected]> wrote: > On Mon, Apr 13, 2009 at 2:51 PM, Guillaume Nodet <[email protected]> wrote: >> Btw, I'm not so sure iPojo is a good candidate for implementing the >> blueprint service. >> I've began doing some testing with xbean-reflect and I am able to >> parse and instanciate very simple beans. >> See: >> >> https://svn.apache.org/repos/asf/geronimo/sandbox/gnodet/blueprint/org.apache.felix.blueprint/src/test/java/org/apache/felix/blueprint/WiringTest.java >> and the blueprint xml >> >> https://svn.apache.org/repos/asf/geronimo/sandbox/gnodet/blueprint/org.apache.felix.blueprint/src/test/resources/test-wiring.xml > > Since you're not using iPojo now there is no point of having two > separate efforts of implementing rfc124. So I think we should merge > into one project. For example, let's take your parser and integrate > with my (and Rick's) code and go from there. I already experimented > with xbean-reflect and I think it might work but will need some extra > modifications. > > Jarek > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com
