Ah, like some of the commenters, I interpreted this line:
"I have config files and various documents that I want to copy from the dev environment to the dev-server directory using Maven2."
To mean a remote dev-server and then maven-upload was mentioned in the list of solutions. Let me step back a bit.
Maven is primarily interested in the process of building. There are functions that allow deployment but generally that is not Maven's domain. Using Maven as part of your deployment process is definitely going to be at odds with a smooth experience. I think of it like making non-default choices in Ruby on Rails, you are asking for pain.
As to your point about "reinventing the wheel" for deployment using maven, I would suggest that there are many tools designed for deployment and would use those instead, like cap.
I can understand making that interpretation at first glance.
I agree that the process of building should be the primary focus of a build tool. I also, think that the secondary purpose is to make development easier. That is why you do 'rake rails' instead of having to use cap to deploy your changes locally. It's not that hard to come across a scenario that falls in to one of these goals that requires custom logic (like copying a file, or something similar). Some of this should go in custom plugins so it can be reused. However, some of it is small and non-generic and makes no sense as a plugin. The solution you pointed to for copying a file involves substantially more code to include and configure the plugin than it would take in other JVM build tools (such as SBT or Gradle) to simply specify that you want to copy a file.
I agree that doing deployment for final builds or to shared environments are better served by a different tool.
"I have config files and various documents that I want to copy from the dev environment to the dev-server directory using Maven2."
To mean a remote dev-server and then maven-upload was mentioned in the list of solutions. Let me step back a bit.
Maven is primarily interested in the process of building. There are functions that allow deployment but generally that is not Maven's domain. Using Maven as part of your deployment process is definitely going to be at odds with a smooth experience. I think of it like making non-default choices in Ruby on Rails, you are asking for pain.
As to your point about "reinventing the wheel" for deployment using maven, I would suggest that there are many tools designed for deployment and would use those instead, like cap.