>> - I'm under the impression there are already well established >> implementations of JSR 330
Well, the problem I see with this very approach is that it says it 'implements JSR-330'. As an EG member I can tell you that atinject is only the least common denominator of the 'user side' of the story. It totally misses how those beans get created, how the scoped are filled, etc. It's really just the common part of Spring, CDI, Guice and EJB. That's basically like specifying a 'book' as a piece with pages with written words on it and packaged in a cover. This definition is fine for storing books in a library but it doesn't say anything about the content. A concrete example: atinject defines @Scope. But how does those beans behave? How do they get stored and how do they get produced? Atinject defines none of those aspects. You would need to invent all of pieces on that side yourself. Otoh OpenWebBeans core defines all this via CDI and has about 450k. Plus a few spec api jars which are not large neither. And this is not even specially trimmed down. We might be able to remove even more stuff (we did not try yet). There is also the possibility to e.g. switch our our default ScannerService and use one where you hand over the classes you like to use via a Set<Class>. In the CDI EG we also currently experimenting with trimming down the functionality of CDI for pure CDI usage by e.g. trimming all the bytecode tinkering. We'd be happy to not only get feedback but also about additional helping hands ;) LieGrue, strub ----- Original Message ----- > From: Phil Steitz <phil.ste...@gmail.com> > To: Commons Developers List <dev@commons.apache.org> > Cc: > Sent: Saturday, 8 November 2014, 22:03 > Subject: Re: Announce: Commons Inject > > On 11/4/14 9:08 AM, Emmanuel Bourg wrote: >> Le 04/11/2014 15:55, Jochen Wiedmann a écrit : >> >>> Any feedback welcome. >> Hi Jochen, >> >> I'm not a dependency injection expert so I can't really comment on > the >> design, I could just make trivial observations like the use of the > 'I' >> prefix for the interfaces which isn't used in the commons components > and >> may lead to some confusing names (IMutableBindingSource is not immutable). >> >> I'm more concerned by the viability of this project as a Apache Commons >> component: >> - Are there other committers interested in maintaining this project? > > That's the right question to ask. >> - Will this be used by other Apache projects? I tend to see Apache >> Commons as the place to factorize common code used across Apache >> projects, I'm not sure it works very well in the other direction. > > Well, [math] is one example of a component that started here and it > has done OK. I suspect most usage of [lang], [collections], > [configuration] and quite a few others are outside apache as well at > this point. >> - I'm under the impression there are already well established >> implementations of JSR 330, what was the motivation behind this >> implementation? What are the selling points of this implementation >> compared to the others? > > Always a good question to ask, but not a blocker. Each time we > start a new JSR-blah thing at the ASF you can ask the same > question. Whoever wants to grow a community around the new thing > has to be able to find some shared itches to make it interesting. > Ollie mentioned one thing. Maybe there are others. >> - Why bringing this in Apache Commons instead of starting on Github? > > Because we have the sandbox here as a place for committers to > experiment with new components. We all see what is going on there, > so starting there also increases the chance that some other commons > committers will get interested in the new thing. > > Phil >> >> Emmanuel Bourg >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org > >> >> > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
