A small brain dump on some of the bad things about Maven 1.0 and it's architecture .

Plugins live in $MAVEN_HOME/plugins.
- There is no documented location for non-maven plugins to persist between installs.
- No documented location for 'single user' plugins for a multi-user install.

Which plugins?
- There's no way to define a list of required plugins for a user or installation. This creates issues across larger installations.

Plugin defaults
- There's no way to provide a standard set of defaults for plugins across a set of developers. The ${user.home}/build.properties file becomes a maintenance issue. It would be better to externalise or parameterise defaults.properties.

Installation
- plugin:download is great, but an 'artifact:download' is needed as well.
- plugin:update is also needed to pick up new releases of existing plugins with a confirmation before install.
- installation should be to either a user-only or system directory.
- Version clashes (e.g. multiple versions of a plugin) should be displayed during the build so that they can be corrected.
- As the ${maven.home}/plugins dir is a single directory, clashes with plugin jar names seem inevitable, and it would seem better to structure the plugins dir like a repo with ${groupId}/plugins directories. e.g. all maven plugins go into ${maven.home}/plugins/maven/plugins, and plugins from sourceforge go into ${maven.home}/plugins/sourceforge/plugins
- Plugin dependencies are not usually provided with plugins. The download/install process should fetch them all rather than waiting until later.

Unzipping
- Plugins are automatically unzipped creating large numbers of directories and files in typically ${user.home}/.maven which are often left over on a new install causing issues

Caching
- Plugins contents are cached into files in ${user.home}/.maven/plugins. Until rc3 this cache would often become corrupt over time with unpredictable results. Once rc3 is out we'll see how this goes.

Plugin classpaths
- Plugins written in Jelly often have clashes with the libraries in use by Maven. The classloaders need to be isolated.
- Classes provided by Maven (ant junit etc) often require classes to be found in their classloader.
- Plugins often have issues with jdk 1.3 and the xml classes.

JDK Differentiation
- There's no easy way to specify dependencies for a project by jdk version (e.g. xml classes needed only for jdk13 etc)

Dependency specification
- There's no way to specify for example a released junit > 3.8, a specific version is always required. Some way to specify 3.x or > 3 would make keeping up to date a lot easier, and specific versions are still required for repeatable build situations.

Plugin information
- Once a plugin is installed, it would be nice to be able to dump info about the plugin (name, url, distribution site, authors, mailing lists etc....)

Goal naming
- Plugins usually define goals with a standard prefix, e.g. myplugin:theGoal. Exceptions to this rule should be reported, and prefixes being reused by other plugins reported as well.