2

My Maven project contains 3 different profiles, dev, stage, and prod, that contain different configuration settings. I would like to make it so that the install and deploy phases cannot be executed (or execute but do nothing) if the active profile is not prod, to keep dev and stage builds out of the repo. Is there a way to do this?

I'm guessing it involves adding the <plugin> to the dev and stage profiles and manually binding it to a "none" phase or something like that.

2 Answers 2

1

If that's what you really want to do, then just run the "package" phase on dev and staging, and in your maven settings file the provided user should not have write privileges to the repository.

What I would recommend doing, though, is to keep your configuration files outside of the build artifact, so that you only have one build that gets promoted between environments. As part of a script for deploying a build, you can automatically copy the correct settings, getting a similar effect.

0

Regardless of whether how you want to do this is the best idea, what you could do is use the Maven Enforcer Plugin to validate that the profile property is set to the value of your 'prod' profile. The plugin binds by default to the validate phase, so you would need to bind it to the package phase, or only the 'prod' profile will be usable.

The specific recipe I would use for this:

There's a built-in rule called requireProperty you can use to make assertions on properties and their values. You could set a property from your prod profile and then (outside any profile) configure the enforcer plugin to check to see that said property is set to the value you expect. This is hokie, however.

I strongly suggest that you externalize environment-specific configuration values into property placeholders and use profiles only to set those values rather than switching out environment-specific config files or affecting the contents of the artifact that you're generating.

4
  • I do, in fact, just use profiles to set placeholders. Each profile defines an $env variable. Then in the parent POM I have a filter set up, referencing filters-${env}.properties. So all configuration information is centralized in those files, one per environment. That doesn't stop someone from doing a mvn -Pdev deploy, though, and polluting the repo with dev-configured artifacts, which is what I'm trying to solve.
    – Jason
    Commented Jul 12, 2011 at 17:16
  • Could you use my suggestion with your env variable, then?
    – Paul Morie
    Commented Jul 12, 2011 at 18:32
  • Yep, I think I can, working on the fix right now. In the long term, I agree that I need to work out a less janky way to accomplish this, but this will get me through the sprint. Thanks!
    – Jason
    Commented Jul 12, 2011 at 18:41
  • I ended up just adding the enforcer plugin to the profiles I didn't want to be able to install or deploy using the AlwaysFail rule with a nice message explaining things. Thanks for the help!
    – Jason
    Commented Jul 12, 2011 at 19:52

Not the answer you're looking for? Browse other questions tagged or ask your own question.