Maven is for building, not deploying

Writing software doesn't help you if you can't install it.  In a simple web environment, Maven works great.  It produced a war file (with every dependency in WEB-INF/lib).  Just drop that war into Tomcat and you are done.  What happens when you have a more complex setup?  Maybe Websphere with an aggregator pom for the jars that go into the Shared lib class loader level?  What about a batch application that is just a bag of jars?  Maven has a copy-dependencies goal that copies the dependencies of the pom file into a directory.  When you call that goal, you may notice something weird.  Why is junit.jar in the extract?  Oh, that's right.  Copy-dependencies ignores the scope tag of your dependencies.  All of your test and provided scoped dependencies are in your extract folder.

The next problem we notice is the lack of context with regards to your scope tags.  Why do you need a context?  Say we have a war file destined for Websphere.  To reduce our memory footprint, we exclude some jars that will be shared among the war files.  To exclude them, we declare the dependencies as 'provided' scoped.  From the context of the war file, those jars are provided by Websphere.  Let's assume we fixed the copy-dependencies problem from above.  Now, we extract the jars that are destined for Sharedlib.  Oh no!  All our jars are missing.  All the jars are marked as 'provided' so nothing was extracted.  From the context of the sharedlib pom, the jars are not 'provided'!  Now we start messing around with the extraction process and duplication of data in pom files.

All of these problems occur because Maven was designed as a build tool.  It has no concept of how to extract and deploy your code (other than a simple war or ear setup).