Maven profiles - dev vs production - maven

Question

I was curious about how to set up development vs production maven profiles. Should I only put the snapshots repo in the dev profile, and the other artifacts (local repo, for releases etc), in the production profile?
What are the major things which different profiles of these types?

Answer 1

The major difference is, obviously, settings among Prod, Test, and Dev profiles. Things like
Database connectivity
Properties like resource settings, thread-pool configuration, log file location and it's size
Storage settings like for local you might have a /mnt/media but for Prod, you may want S3
varies in these profiles.
Now come to release, usually Test profile/s has SNAPSHOT releases (like nightly builds) that is configured to go to SNAPSHOT repository of yours. And a Prod profile is released, usually, using Maven Release Plugin, that automatically knocks the SNAPSHOT off your release version/artifacts. And is configured to store the artifact in RELEASES repo. The configuration for these repos goes like
<profile>
<id>test</id>
<distributionManagement>
<snapshotRepository>
<id>snapshotrepo</id>
<name>Repository for snapshots only</name>
<layout>default</layout>
<uniqueVersion>false</uniqueVersion>
<url>http://repo.company.com/snapshots</url>
</snapshotRepository>
</distributionManagement>
.....
.....
.....
<profile>
<id>prod</id>
</distributionManagement>
<repository>
<id>releaserepo</id>
<name>Final release artifacts</name>
<layout>default</layout>
<uniqueVersion>false</uniqueVersion>
<url>http://repo.company.com/releases</url>
</repository>
</distributionManagement>
....
....
The credential to these repos goes into settings.xml.
Dev profile is usually not configured to release to company repo (as it will be too cluttered of useless artifacts), it just gets installed in your local repo, as SNAPSHOT and overwritten on each build.

Answer 2

Usually (in my experience) the different repos are configured in settings.xml, and not in separate profiles (except maybe in profiles enabled by default).
Example of a default profile:
<profile>
<id>default</id>
<activation>
<activeByDefault>true</activeByDefault>
</activation>
<repositories>
<repository>
<id>central</id>
<url>http://some_url/content/groups/public</url>
<snapshots>
<enabled>false</enabled>
</snapshots>
</repository>
<repository>
<id>snapshots</id>
<url>http://some_url/content/groups/public-snapshots</url>
<releases>
<enabled>false</enabled>
</releases>
</repository>
</repositories>
If you are concerned about having SNAPSHOT dependencies in your releases, you can use tools like maven-release-plugin to verify that there are no SNAPSHOT dependencies in your project.
What are the major things which different profiles of these types?
You often use profiles to separate between different build environments. For instance, using a CI you often put plugins for static code analysis, reporting, test coverage etc. in a profile that is only activated when building on the CI server (since it takes more time to run it with these tools enabled).
Another use is to separate out specific part of the application, for instance you don't want the acceptance-test submodule to run on every mvn test, but only sometimes when you enable the mvn test -p acceptanceTests profile
The problem with environment specific builds
Now, profiles are sometimes used to separate configurations like connections strings, enpoints etc. In my view that is not ideal, since you end up with environment specific builds. Sometimes that is hard to avoid, but most of the time this can be solved by externalizing configuration (make sure to have proper configuration management), and use the same binary artifact in dev/test/prod. That way you are sure that the build that passed system test is the same as that in prod etc.