Use maven profiles for developer sandbox settings?

Question

I've seen several projects where I work that use profiles.xml and various {username}.properties in the project for developer sandbox settings like the deployment directory for the deploy script, the ports to run on, which database and web service to use, etc. Now that Maven 3 has removed support for profiles.xml, it's caused me to question this practice altogether. So I have a few questions:

1. Is there a better mechanism rather than profiles to accomplish this?
2. If not, do you feel {username}.properties belong in the scm? Sometimes (for example) when a service URL changes, we forget to update all the developers' properties.
3. If it's not a bad idea to have these properties files in the scm, should there be some kind of profile inheritance for settings common between developer sandboxes? How could that be done?
4. As a side note, do you know why Apache removed support for profiles.xml in Maven 3?

Answer 1

As you said, Maven 3 only has removed the support for external profiles.xml files. You can still use profiles in the settings.xml and, as always, in the pom.xml. Those projects that currently have external profiles.xml files, should move those configurations to the local user's settings.xml file.

1) There really isn't a better mechanism than the profiles configuration for managing environment specific values.

2) User property files in the scm depends on the content that you have and whether or not that information is sensitive to others who may look at it. If you structure your source tree right, there should be no issue storing it in your SCM.

3) In the past with other projects I've worked on, we kept a separate directory next to the tags, trunk, and branches with SVN called configurations that had a base directory that contained a template of what the configuration file(s) should look like and developers folder and a servers directory. From the base directory, developers would create/branch their own directories under the developers directory that had their own copy of the configuration files. This allowed them to merge changes to the base version and update 'their' configuration. This solved a lot of those service URL changes and would allow them to do it on their time.

4) Not a clue. Could a be a hold over from Maven 1 that they wanted remove.

Oh, don't forget, with Maven 2.2 and 3.0, you can encrypt values in the settings.xml.

Answer 2

Is there a better mechanism rather than profiles to accomplish this?

No, profiles are still perfect for this.

If not, do you feel {username}.properties belong in the scm? Sometimes (for example) when a service URL changes, we forget to update all the developers' properties.

I would typically place user specific properties in the ~/.m2/settings.xml and common properties in the pom.xml file.

If it's not a bad idea to have these properties files in the scm, should there be some kind of profile inheritance for settings common between developer sandboxes? How could that be done?

If you want to benefit from inheritance, my suggestion would be to use maven <properties>.

As a side note, do you know why Apache removed support for profiles.xml in Maven 3?

The support of profiles.xml was making Maven internals complicated and hard to test. And because using settings.xml is an acceptable alternative for most cases, profiles.xml has been dropped. See the following thread (in particular Jazon's messages).