Home/ Questions/Q 3401898
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-18T05:04:20+00:00

I’ve seen several projects where I work that use profiles.xml and various {username}.properties in

  • 0

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?
Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    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.

    • 0