feature-comparison.apt

 ------
 Plexus Feature Comparison
 ------
 Brett Porter
 Rahul Thakur
 ------
2006-05-27
 ------

 <<<The contents of this document are a work in progress>>>

How does Plexus compare with Spring (1, early 2000)?

  * <<Plexus is simpler and much much smaller than Spring.>>

  The simplest Spring Component which has configuration settings injected is 
  more complex than in an equivalent case for Plexus as Plexus does not require
  setters.

  * <<Spring attempts to be a Swiss Army knife.>>

  Spring tries to sell itself as a "j2ee framework" and as a Swiss Army knife -
  one framework for all possible problems. 
  
  Plexus is a container that is also usable in the context of application 
  deployment to the j2ee platform. It also competes with pico/nano containers 
  at the low end (plexus jars are still under 1 mb).  Plexus Application Server
  (which is build on top of Plexus container) can be used as a replacement for 
  j2ee application servers. So for example, users can deploy ftp or http 
  servers with plexus. Users are free to compose their application only from 
  the pieces (jars and components) that they really need. Instead of a Swiss 
  Army knife you can use better tools:  hammer, screwdriver as you need to use 
  them without having to include them all.

 * <<Complex component life cycles are not supported in Spring.>>

 * <<Spring configuration files are much longer than the one for Plexus.>>

  Specifically hierarchical configuration settings ala xstream are not
  supported by Spring.

 * <<Spring is not using IoC for all dependecies of components.>>

  For example Spring is promoting terrible things like logging based on commons-logging,
  which makes most of the component dependent on an ugly singleton (IoC is 
  against singletons!) and inevitably leads to incorrect class loader 
  hierarchies (commons-logging must be in root classloader of the container).

 * <<Missing notion of "Component identity">>

  Spring doesn't allow you to direct logging output from two deployed instances
  of the same component/bean to different files (unless you use AOP). This is
  due to the fact that "component identity" is not propagated or understood by
  the logging system. In Plexus such things are possible - but not yet
  implemented.

 * <<Component class loader isolation.>>

  Spring doesn't allow you to easly deploy two distinct components which are 
  using conflicting version of "the same" jar (e.g. common-collections-2.x and
  commons-collection-3.x). for their internal stuff.

 * <<In Plexus you don't have to repeat yourself.>>

  Component descriptors which are in jars contain the facts which are needed 
  by the container to manage components. Component personalities provide useful 
  shortcuts for saying to container this is "avalon component", this is "pico 
  component", so you don't have to redefine that for every component.