The Syringe API lends itself to setting things up with code. The HiveMind API wasn't really meant for that. It was written with the hivemodule.xml file syntax in mind and with everybody chanting "less XML is good", we've had some folks requesting a more API-based approach. So, you're right, Siringe is indeed a framework, but it's a lower-level framework. Something like HiveMind would sit on top of syringe (as painful as that may sound). I would like, someday, to port HiveMind to use the Syringe API underneath, but that would be quite an undertaking and there are quite a few folks out there already using HiveMind (anyone using the newest Tapestry, for example). I wanted to start something fresh with no limitations of backward compatibility and see what I came up with. Hopefully folks with think that Syringe is easy to use/extend. I'm working on an example application right now to see how really easy it is (eat my own dog food). Hopefully the example will serve as documentation and an opportunity to figure out how to make Syringe that much more usable.
Since it is a framework, would I have to submit a "Jakarta PMC TLP Application" if I wanted to eventually move this project to Apache? Is there no real "incubator" inside Jakarta for projects such as this? Sounds like I may have chosen the right place for this project for now. -----Original Message----- From: Stephen Colebourne [mailto:[EMAIL PROTECTED] Sent: Friday, August 05, 2005 8:39 AM To: Jakarta Commons Developers List Subject: RE: Project Proposal? While interesting, this would have caused issues in commons. The commons charter explicitly avoids frameworks, and this is definitely a framework. Longer term though, with Spring, Hivemind and Pico already in this space, and EJB3 making some moves there must be a limit on having a new injection framework. So, why not just improve Hivemind? Stephen --- James Carman <[EMAIL PROTECTED]> wrote: > I guess I wanted a little more freedom/control over > the project at this > phase. Also, I wasn't too sure about licensing > issues with putting stuff in > the codebase that depends upon code outside Apache > (the build file > automatically downloads its dependencies from > Ibiblio). > > It is early on right now, but I think there are some > sound ideas there... > > 1. Proxy Factories - All proxies in Syringe are > created using a proxy > factory (an interface). Using syringe, you never > have to write the proxying > logic code yourself anymore. Furthermore, since > it's abstracted out, it's > easy to switch between (or mix and match for that > matter) proxying > strategies, simply by supplying a different > implementation class. I > currently have implementations using JDK proxies and > CGLIB. > > 2. Object Providers - Objects are provided to > Syringe through > ObjectProviders. There are two different types of > ObjectProviders now, core > object providers and wrapper/decorator providers. > The core providers would > be responsible for constructing/finding the actual > implementation object. > It might be a simple JavaBean, or it could be some > sort of remote object > (EJB, JAX-RPC, RMI, Burlap, etc.). The > wrapper/decorator providers > supplement these core providers with additional > functionality. For example, > in Syringe, all dependency injection is done using a > decorator provider. > So, it's easy for you to extend Syringe with your > own providers and still > support DI. This has been somewhat of a problem in > HiveMind. All of the > dependency injection logic is buried inside the > BuilderFactory's > implementation. > > 3. Method Interceptors - Syringe only supports the > MethodInterceptor > interface (a proxy factory must know how to create a > proxy which goes > through a MethodInterceptor) from the AOP Alliance > API. Since this is > somewhat of a "standard" API, I don't really see it > as a limitation. If we > see the need to support other mechanisms, maybe we > can provide adapter > classes to bridge the gap. > > > > -----Original Message----- > From: Henri Yandell [mailto:[EMAIL PROTECTED] > Sent: Friday, August 05, 2005 2:37 AM > To: Jakarta Commons Developers List > Subject: Re: Project Proposal? > > Out of interest, why java.net and not sandbox? :) > > Before that sounds like a witch-hunt, I'm as guilty > in that I start > all my stuff at osjava.org and I can definitely list > some reasons why. > > Some may be bad: > * Embaressment for dumb ideas :) > * Don't want to be weighed down by a weighty release > system. > * Big painful website. > * Might compete with another Commons component. > > Some may be good: > * Does the ASF want single-person codebases when an > idea doesn't pan out. > * If it fails, I'd then be forking it elsewhere > which feels worse than > just starting elsewhere. > > What if we had a location within which ASF > committers can bring their > half-cocked component ideas? Try to encourage > migration to the ASF and > its benefits: > > * bandwidth, though sf.net and java.net can solve > that too. So can > building your own system to the level of Codehaus. > * legal protection. > * better user acceptance. > * community. > > If we couple this with: > > * much better management of the sandbox, and > components that have failed. > * a plan for mature components. > > could we pick things up in terms of vibrancy? My > biggest worry would > be whether the mailing list becomes a bottleneck. > > Half-baked idea (it's late): Each component has its > own mail alias > which gets forwarded to particular lists. These > lists could represent > the state of maturity of a component. Probably crap, > just throwing it > out. > > One question I'd like to ask is whether we would > accept mature components. > > Take http://www.osjava.org/norbert/, HttpClient said > they were > interested in using it and the thought was to put it > in Commons. My > only concern is that I can't see a lot more to do > with it code-wise, > so I'm hesitant to dump it in Commons, and yet I > think it's a good > tiny component that could do with being more open. > > Hen > > On 8/4/05, James Carman <[EMAIL PROTECTED]> > wrote: > > Well, I went ahead and started the project over at > java.net, but we can > move > > it later if need be. It's a dependency injection > framework called > > "syringe." The project uses the Apache License, > Version 2.0. It's still > > "pending approval" at java.net, so you guys won't > be able to see anything > > yet. It should be approved soon though. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: > [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: > [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
