Avoid Project Structure Funkiness
Injecting a lot of Ant code via the "maven-antrun-plugin" in your POM is a leitmotif of non-portability. If you find that other Maven plugins routinely fall short of your requirements, it is smart to look first at your project structure.
This leads me into another nefarious piece of Maven non-portability: project nesting. For example, nesting WARs in EARs like so:
Before Maven, this was a common setup for projects that consisted of a WAR with a single EAR. Antenforcing no structure at allhappily obliged. Sometimes people attempt to port structures like this to Maven and build projects via embedded Ant or with the "maven-assembly-plugin". Say you write such a project for a single customer. Then, along comes a new customer who requires a different EAR configuration. Your WAR is logically a separate project, but porting it into another EAR proves quite difficult. Your ability to port this project to a new customer is now limited.
This is an example of attempting to force Maven non-standard project structures into the Maven framework. In this particular example, you should split the EAR and WAR into separate projects, like this:
Have a new client with a new EAR? No problem, just add a new EAR project with a dependency on
myWar. Don't worry; you'll learn to love it.
Create Your Own Public Repository
If your project has dependencies that exist on a repository other than Maven-central, consider creating a public repository of your own. This will require a public Web server, some mechanism to deploy files to that Web server's filesystem, such as an FTP server, and a few changes to your POMs. Many articles on the Web explain how to install and set up your transport mechanism of choice, but this example uses WebDAV to accept project uploads. After your servers are configured, create a parent POM from which all of your projects may inherit. This makes deployment much simpler. Add the following to a parent POM:
The URL prefix corresponds to one of the supported Wagon providers, the mechanism that Maven uses to transport your files to the correct repository. (Click here for the list of supported provider types.) Besides specifying the distribution management, you must add a build extension corresponding to the transport mechanism you wish to use. In this case, WebDAV, so I added "wagon-webdav".
In order to control who may deploy their builds to this server, you will probably assign your core developers usernames. Each user can set up his or her settings.xml files (under their Maven install conf or local repository directories) to the matching repository ID, as follows:
Requiring a change to your developer's local setup in this way does not really affect portability. You are concerned with only your client builder's ability to build and install without making local changes. That does not mean you want to make it easy for them to deploy to your repository.
Now for any project that depends upon other deployed projects, you can add the public face of your repository (made public by a simple Web server, such as Apache HTTP Server) via the repository element, like this:
Your project is now widely portable. If you wish to be merely in-house portable, you can restrict network access, effectively creating an exclusive club for your repository (all you need is the secret handshake).