|
| RelatedProjects |
UserPreferences |
| JicarillaWiki | FrontPage | Overview | Articles | GetStarted | Sourceforge Project Page | RecentChanges |
This wiki is in 'slumber' mode, just like its associated sourceforge project. Edits are disabled, the content is potentially stale and is not maintained. That said, it contains some really useful stuff still. Enjoy!
LinkingToTheCompetition seems to be forgotten a lot these days. Me, I'm not looking to build a successful project, nor make money, so I thought I'd point you at some other stuff.
I use various abbreviations and terms on this page that may be unfamiliar to you. See http://wiki.codehaus.org/picocontainer/PicoTerminology
Seems to be hot technology. AOP, in lightweight form, is finally catching up.
pioneered AOP in java. Language extension. Which is why, though powerful, it won't fly.
one of the first interceptor-based AOP toolkits that doesn't require a language extension.
similar in scope and purpose to Nanning, but the implementation is quite different (hooks into the classloader and does bytecode).
the only stable 'open source' J2EE container (but watch ![[WWW]](/oldwikiskin/img/moin-www.gif){kind=small}
Geronimo). Are exploring various setups including AOP to improve on the mess that is EJB. Lots of mindshare. My opinion: too big, too much xml, and the bytecode hassle isn't worth it.
It starts with CompositionOverInheritance, leads to SeperationOfInterfaceAndImplementation, and its not such a new idea.
IoC, SoC, SAI, DecP, EBP (EBP for fortress only). One of the oldest IoC projects out there. My opinion: too big while doing too little. Big committer base, mature codebase, mature ASF project (which can be a good thing and a bad thing rather extensive 'avalon-framework' (comparatively heavy compared to more recent developments) that defines the contracts between a component and a container. Has 3 container projects to consider: avalon-phoenix, a mature microkernel design, avalon-fortress, similar in weight and featureset to something like nanocontainer with a 1.0 release (successor to avalon-ecm, the container used in (among other projects) apache-cocoon), and avalon-merlin, a more recent development which they _seem_ to be converging on as the successor to all other previously produced containers. Arguably the biggest, most extensive and most dynamic IoC container implementation around (and hence also the most complex).
IoC, SoC, SAI, (optional: AOP, DecP). pioneering a simpler IoC, many ThoughtWorks and XP folk around. Lean and mean and very extensible and embeddable, developed by smart XP peeps, some stuff already in use in some apps, but otherwise pretty much alpha. I love picocontainer and the way they're doing the project. The dev community is intentionally kept small atm, but many peeps are watching this one. My opinion: might just be it.
IoC, SoC, SAI, DecP. started as a fork of avalon-phoenix, will now (slowly) be refactored to utilize and build upon PicoContainer. Should add some of the advanced features you lose when you move from avalon to pico. Includes a type-1 IoC container-component contract package (ie similar to Avalon-Framework) called DNA and a container implemention called Loom.
started (IIRC) as a container for avalon components, refactoring to support various component lifecycles now probably complete. I expect lots of synergy between JContainer and Plexus. Haven't looked at it for a while.
used to be a fast growing project but is currently down because of some licensing things to figure out. Contains some stuff refactored out of Tapestry. Has clever usage of JavAssist (http://www.csg.is.titech.ac.jp/~chiba/javassist/). Draws ideas from the eclipse platform. Have yet to look at it in detail.
a small project by a polish company that builds upon PicoContainer, adding some of JContainer's DNA features, a small but growing suite of components, and a customized pico container implementation to make working with all of that easier.
These projects are very similar to what I'm exploring with Jicarilla.
IoC, SoC, SAI, AOP, DecP, EBP. Nearing 1.0 release. Applies this stuff to the web domain. My opinion: XXXAware sucks, EverythingIsAnEvent is counterintuitive, the command pattern is just as counterintiuitve, too closely coupled to client/server/web assumptions. But if I were to place a bet on which of the above tech is actually going to last, it's either these peeps or JBoss. IoC, SoC, SAI, AOP, DecP, EBP. Nearing 1.0 release. EBP very basic only. Lean and mean, but not mature and some client-server web-layer specific assumptions. Don't like the XXXAware interfaces. Very vibrant and active community and many famous peeps with J2EE experience around at opensymphony.
some of the same ideas, but way too much J2EE and too much xml. An interesting critique of PicoContainer is at http://www.springframework.org/docs/lightweight_container.html. Lots of other good documentation as well. But why on earth does everyone try and solve all problems by throwing away all type safety in favor of xml-based declaration and programming?
Spring's "BeanFactory" container functionality does not depend on any J2EE APIs. It's pure Java. You can use it without an app server or even a web container. Maybe we should do a Spring Java release to make this clear. (Rod Johnson)
And update the website, perhaps. From the front page: "Spring is a J2EE application framework" (LSD)
Pointers to IoC components and/or repositories of IoC components.
Other indexes of IoC components and containers.
The page of avalon-related projects maintained by the avalon project.
The page of PicoContainer-related projects maintained by the PicoContainer project.
