Comments on M2 Use cases

[Jerome Lacoste <je...@coffeebreaks.org>]

- specification dependencies: even if one specification is specified,
one should be able to define the required implementation. This to solve
problems like implementation bugs or unneeded dependencies e.g. one
implementation reuses a unneeded, unwanted or conflicting dependency.

- scalable and manageable repository layout
  There are plenty of experience to retrieve from Linux repository
handling. E.g. In most of them you point to a repository definition,
which is resolve as a file containing allowing to resolve the packages
into a location. That allows for letting people decide how to make the
mapping locally. That seems to be more flexible to what maven does now.
Maybe it should be looked into. 

Note: that would solve my problem of being able to reuse my Linux local
build. Creating a maven-repository location file would allow me to say
that artifact is on /usr/share/java/xxx-version.jar, that artifact is in
/usr/share/log4j/.... etc...

- security : whatever solution is defined on the server side, we should
also provide either a framework or an advised methodology to guide
someone with its setup. Maven is afterall, also defining the best
practises.

- plugin: design. 
  - persistence of post-execution errors? Might be useful in terms of
crash handling, container restart, ...
  - thread safe singletons: as Vincent, I believe that avoiding
singletons but letting the client define its managing policy is better.
Thread safe is still necessary of course, but it is not sufficient
against . Sometimes, if an implementation keeps track of client related
state in its plugin, then thread safety is not sufficient. Instead of
making the plugin implementation more complex, maybe letting the clients
use a different instanciation strategy. like a pool, or anything else,
might be more appropriate.




New non.functional requirements:
- better feedback when downloading (cf. the issue I opened on maven1)
- easy integration with external tools, especially graphical ones (IDEs)